Reusable AI capability
Define Versioned Metric Contracts for Analytics Alignment
Turn disputed or ambiguous business metrics into governed, testable semantic contracts with explicit grain, calculation rules, lineage, ownership, access constraints, and change-control expectations.
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.
# Define Versioned Metric Contracts for Analytics Alignment Skill ID: AMO-S-000031 Skill URL: https://amo.ng/skills/define-versioned-metric-contracts-for-analytics-alignment Purpose: Creates a reusable metric-definition contract that helps analytics, finance, product, and BI teams reconcile metric disputes and maintain consistent reporting across dashboards, warehouses, and semantic layers. Required inputs: - Metric name, business purpose, and decisions the metric will support. - Current definitions, formulas, dashboard references, SQL snippets, semantic-layer definitions, or documentation. - Source systems, tables, fields, data grain, refresh cadence, and known lineage. - Time logic, filters, exclusions, attribution rules, segmentation rules, and currency or timezone handling where applicable. - Known discrepancies, stakeholder disputes, downstream reports, and affected audiences. - Required governance constraints, owners, approvers, access restrictions, and change-management expectations. - Authoritative metric owner and approvers, current contract version, compatible producer and consumer versions, lineage evidence, and downstream change owners. How to use: When to use: - Teams disagree on how a KPI is calculated, filtered, attributed, or time-bucketed. - A dashboard, report, or semantic layer needs metric definitions that are testable and version controlled. - A metric appears in multiple tools with conflicting results or unclear lineage. - A new or revised KPI needs ownership, access rules, acceptance checks, and migration guidance before adoption. When not to use: - Do not use as a substitute for executing SQL reconciliation or validating raw data quality when the issue is primarily data corruption. - Do not use for a one-off chart request where metric definitions are already stable and governed. - Do not use to make final financial, regulatory, board, or compensation decisions without human review of evidence and calculations. - Do not use when the metric owner, intended decision, or source systems are unknown; clarify those first. Instructions: 1. Use the linked source prompt AMO-P-000263 as the contract-design scaffold; apply its structure to the supplied metric context without reproducing the entire source. 2. Identify the metric’s intended decision use and the risks of inconsistent interpretation. 3. Separate supplied definitions from assumptions, inferred business rules, missing lineage, and unresolved stakeholder decisions. 4. Define the metric contract: name, description, grain, entities, calculation, time window, eligibility rules, exclusions, dimensions, source lineage, freshness expectations, and permitted uses. 5. Specify validation checks such as reconciliation queries, row-count checks, aggregate comparisons, edge-case examples, dashboard parity tests, and acceptance thresholds. 6. Document the authoritative metric owner, contract version, producer and consumer compatibility, lineage evidence, approval workflow, downstream impact, deprecation or migration path, and communication requirements for metric changes. 7. Flag access-control, privacy, compensation, finance, compliance, or executive-reporting implications for appropriate human review. 8. Avoid overstating readiness; provide a status such as ready, ready with conditions, needs reconciliation, or blocked by missing evidence. Expected output: A metric contract package containing the agreed definition, lineage map, validation checklist, governance owners, versioning and migration rules, unresolved questions, and a decision-use readiness status. Constraints and boundaries: - Do not invent source-system schemas, formulas, stakeholder agreements, or reconciliation results. - Do not present a metric as authoritative until its owner and validation evidence are supplied or explicitly approved. - Keep business recommendations separate from approval authority. - Preserve uncertainty around ambiguous data grain, time logic, attribution, or exclusions. - Require human review for financial reporting, investor reporting, compensation, compliance, or other consequential metric use. Based on Prompt: Metric Definition Contract and Semantic Layer Blueprint Source ID: AMO-P-000263 https://amo.ng/prompts/metric-definition-contract-semantic-layer-blueprint Completion criteria: Complete when: - The metric definition includes grain, calculation, filters, time logic, dimensions, and source lineage. - All disputed assumptions and unresolved decisions are listed with owners or follow-up questions. - Validation checks are concrete enough for an analyst or analytics engineer to implement. - Permitted and non-permitted uses are explicit. - The readiness status is supported by the supplied evidence and does not exceed it. - Downstream changes identify affected owners, compatibility conditions, validation evidence, and explicit approval before adoption. Use this Amo.ng Skill with your preferred AI tool. Supply the required inputs and follow the usage instructions. # Define Versioned Metric Contracts for Analytics Alignment Skill ID: AMO-S-000031 Skill URL: https://amo.ng/skills/define-versioned-metric-contracts-for-analytics-alignment Purpose: Creates a reusable metric-definition contract that helps analytics, finance, product, and BI teams reconcile metric disputes and maintain consistent reporting across dashboards, warehouses, and semantic layers. Required inputs: - Metric name, business purpose, and decisions the metric will support. - Current definitions, formulas, dashboard references, SQL snippets, semantic-layer definitions, or documentation. - Source systems, tables, fields, data grain, refresh cadence, and known lineage. - Time logic, filters, exclusions, attribution rules, segmentation rules, and currency or timezone handling where applicable. - Known discrepancies, stakeholder disputes, downstream reports, and affected audiences. - Required governance constraints, owners, approvers, access restrictions, and change-management expectations. - Authoritative metric owner and approvers, current contract version, compatible producer and consumer versions, lineage evidence, and downstream change owners. How to use: When to use: - Teams disagree on how a KPI is calculated, filtered, attributed, or time-bucketed. - A dashboard, report, or semantic layer needs metric definitions that are testable and version controlled. - A metric appears in multiple tools with conflicting results or unclear lineage. - A new or revised KPI needs ownership, access rules, acceptance checks, and migration guidance before adoption. When not to use: - Do not use as a substitute for executing SQL reconciliation or validating raw data quality when the issue is primarily data corruption. - Do not use for a one-off chart request where metric definitions are already stable and governed. - Do not use to make final financial, regulatory, board, or compensation decisions without human review of evidence and calculations. - Do not use when the metric owner, intended decision, or source systems are unknown; clarify those first. Instructions: 1. Use the linked source prompt AMO-P-000263 as the contract-design scaffold; apply its structure to the supplied metric context without reproducing the entire source. 2. Identify the metric’s intended decision use and the risks of inconsistent interpretation. 3. Separate supplied definitions from assumptions, inferred business rules, missing lineage, and unresolved stakeholder decisions. 4. Define the metric contract: name, description, grain, entities, calculation, time window, eligibility rules, exclusions, dimensions, source lineage, freshness expectations, and permitted uses. 5. Specify validation checks such as reconciliation queries, row-count checks, aggregate comparisons, edge-case examples, dashboard parity tests, and acceptance thresholds. 6. Document the authoritative metric owner, contract version, producer and consumer compatibility, lineage evidence, approval workflow, downstream impact, deprecation or migration path, and communication requirements for metric changes. 7. Flag access-control, privacy, compensation, finance, compliance, or executive-reporting implications for appropriate human review. 8. Avoid overstating readiness; provide a status such as ready, ready with conditions, needs reconciliation, or blocked by missing evidence. Expected output: A metric contract package containing the agreed definition, lineage map, validation checklist, governance owners, versioning and migration rules, unresolved questions, and a decision-use readiness status. Constraints and boundaries: - Do not invent source-system schemas, formulas, stakeholder agreements, or reconciliation results. - Do not present a metric as authoritative until its owner and validation evidence are supplied or explicitly approved. - Keep business recommendations separate from approval authority. - Preserve uncertainty around ambiguous data grain, time logic, attribution, or exclusions. - Require human review for financial reporting, investor reporting, compensation, compliance, or other consequential metric use. Based on Prompt: Metric Definition Contract and Semantic Layer Blueprint Source ID: AMO-P-000263 https://amo.ng/prompts/metric-definition-contract-semantic-layer-blueprint Completion criteria: Complete when: - The metric definition includes grain, calculation, filters, time logic, dimensions, and source lineage. - All disputed assumptions and unresolved decisions are listed with owners or follow-up questions. - Validation checks are concrete enough for an analyst or analytics engineer to implement. - Permitted and non-permitted uses are explicit. - The readiness status is supported by the supplied evidence and does not exceed it. - Downstream changes identify affected owners, compatibility conditions, validation evidence, and explicit approval before adoption.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
Creates a reusable metric-definition contract that helps analytics, finance, product, and BI teams reconcile metric disputes and maintain consistent reporting across dashboards, warehouses, and semantic layers.
Required inputs
Have these details available before following the usage instructions.
- Metric name, business purpose, and decisions the metric will support.
- Current definitions, formulas, dashboard references, SQL snippets, semantic-layer definitions, or documentation.
- Source systems, tables, fields, data grain, refresh cadence, and known lineage.
- Time logic, filters, exclusions, attribution rules, segmentation rules, and currency or timezone handling where applicable.
- Known discrepancies, stakeholder disputes, downstream reports, and affected audiences.
- Required governance constraints, owners, approvers, access restrictions, and change-management expectations.
- Authoritative metric owner and approvers, current contract version, compatible producer and consumer versions, lineage evidence, and downstream change owners.
How to use this Skill
When to use:
- Teams disagree on how a KPI is calculated, filtered, attributed, or time-bucketed.
- A dashboard, report, or semantic layer needs metric definitions that are testable and version controlled.
- A metric appears in multiple tools with conflicting results or unclear lineage.
- A new or revised KPI needs ownership, access rules, acceptance checks, and migration guidance before adoption.
When not to use:
- Do not use as a substitute for executing SQL reconciliation or validating raw data quality when the issue is primarily data corruption.
- Do not use for a one-off chart request where metric definitions are already stable and governed.
- Do not use to make final financial, regulatory, board, or compensation decisions without human review of evidence and calculations.
- Do not use when the metric owner, intended decision, or source systems are unknown; clarify those first.
Instructions:
1. Use the linked source prompt AMO-P-000263 as the contract-design scaffold; apply its structure to the supplied metric context without reproducing the entire source.
2. Identify the metric’s intended decision use and the risks of inconsistent interpretation.
3. Separate supplied definitions from assumptions, inferred business rules, missing lineage, and unresolved stakeholder decisions.
4. Define the metric contract: name, description, grain, entities, calculation, time window, eligibility rules, exclusions, dimensions, source lineage, freshness expectations, and permitted uses.
5. Specify validation checks such as reconciliation queries, row-count checks, aggregate comparisons, edge-case examples, dashboard parity tests, and acceptance thresholds.
6. Document the authoritative metric owner, contract version, producer and consumer compatibility, lineage evidence, approval workflow, downstream impact, deprecation or migration path, and communication requirements for metric changes.
7. Flag access-control, privacy, compensation, finance, compliance, or executive-reporting implications for appropriate human review.
8. Avoid overstating readiness; provide a status such as ready, ready with conditions, needs reconciliation, or blocked by missing evidence.
Expected output:
A metric contract package containing the agreed definition, lineage map, validation checklist, governance owners, versioning and migration rules, unresolved questions, and a decision-use readiness status.
Constraints and boundaries:
- Do not invent source-system schemas, formulas, stakeholder agreements, or reconciliation results.
- Do not present a metric as authoritative until its owner and validation evidence are supplied or explicitly approved.
- Keep business recommendations separate from approval authority.
- Preserve uncertainty around ambiguous data grain, time logic, attribution, or exclusions.
- Require human review for financial reporting, investor reporting, compensation, compliance, or other consequential metric use.
Based on an Amo.ng Prompt
Metric Definition Contract and Semantic Layer Blueprint
Open the linked Prompt to read the instructions this Skill is based on.
Open prompt
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.
Completion criteria
Complete when:
- The metric definition includes grain, calculation, filters, time logic, dimensions, and source lineage.
- All disputed assumptions and unresolved decisions are listed with owners or follow-up questions.
- Validation checks are concrete enough for an analyst or analytics engineer to implement.
- Permitted and non-permitted uses are explicit.
- The readiness status is supported by the supplied evidence and does not exceed it.
- Downstream changes identify affected owners, compatibility conditions, validation evidence, and explicit approval before adoption.
Was this useful?
Explore related Workflows
Browse WorkflowsImplement an Operations Dashboard and Automated KPI Reporting
Govern metric definitions, specify the dashboard, implement the dashboard and disabled recurring report, then reconcile both products to authoritative evidence before decision use.
Related Prompts
Browse PromptsReview an Audit Sampling and Control-Test Design
Challenge a proposed audit sampling and control-test design for population coverage, selection logic, evidence requirements, exception handling and defensible inference before testing begins.
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.
Analytical Conclusion Sensitivity Review
Test whether a consequential analytical conclusion survives plausible changes to data, cohort, definitions, assumptions, model choices, and missing-information treatment.
Data Lineage Break Investigation
Reconstruct where a data product diverged from authoritative lineage, bound affected outputs and decisions, and define safe repair and reprocessing.
Forecast Assumption and Model Drift Challenge
Challenge forecast assumptions, structural stability, backtest evidence, scenario sensitivity, and decision thresholds before relying on projected outcomes.
Knowledge Entitlement Drift Review
Reconcile authoritative access policy with effective permissions across source, ingestion, index, cache, retrieval, citation, and response layers.