Guided multi-step workflow
Build 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.
# Build a Governed KPI Dashboard from Approved Metric Definitions Workflow ID: AMO-W-000042 Workflow URL: https://amo.ng/workflows/build-a-governed-kpi-dashboard-from-approved-metric-definitions ## Outcome A dashboard change set and release-review record tracing each approved metric through source fields, query stages, dashboard components and reconciliation evidence. Includes access and data-state tests, unresolved variances, decision-use restrictions, monitoring and rollback handoff. Publication or deployment is a separate authorized action. ## Before you begin - Already-approved metric contracts with stable IDs, formulas, grain, population, exclusions, units, time rules, owners and approval evidence. Bring approved targets and tolerances where applicable; unresolved definitions block affected metrics. - Approved dashboard decisions, audience, views and boundaries; source-of-record designations and authoritative control totals for matching periods and populations. - SQL dialect, schema or data dictionary, lineage, source-field evidence, existing queries and sanitized fixtures or authorized read-only results. - Authorized repository and test environment, existing working-tree changes, allowed files/actions and access/tenant/privacy rules. Never supply production credentials or unnecessary personal data. - Acceptance criteria, permitted test scope, freshness/performance expectations, release authority, monitoring responsibilities and rollback controls. - Start after metric approval. Use the separate operations-dashboard/reporting journey when metric-definition governance or recurring report automation is required. ## Step 1 — Confirm approved metric inputs and dashboard requirements **Prompt** Dashboard Requirements Specification Prompt **Instructions** Run the source Prompt in ChatGPT with the already-approved metric catalogue and dashboard decision brief. Treat its KPI dictionary as a faithful restatement of supplied approved contracts, not a new metric-design exercise. Preserve formula, grain, population, exclusions, time logic, targets and approval references exactly. Map approved metrics to dashboard views, interactions, access and acceptance evidence. Record missing or conflicting approval/source details as blockers; do not invent definitions or targets. Produce the dashboard specification and evidence-gap register. **Input for this step** Provide approved contracts, decision/users brief, dashboard artifacts, source inventory, access requirements and acceptance criteria. Scope is dashboard implementation only; subscriptions, scheduled reporting and external delivery remain excluded. Supply the source Prompt fields: Dashboard objective and scope; Users and decisions; Metric definitions and targets; Data sources and constraints; Interaction and delivery needs; Governance and operational constraints; Existing artifacts and acceptance criteria. Keep absent information explicit; do not invent values. **Carry forward** After metric and dashboard owners review, edit and approve the scope, unchanged metric dictionary, component requirements, access boundaries and unresolved-input register. Complete only when the intake decision is recorded; blocked metrics do not advance to implementation. **Review note** Metric owners confirm the contracts are approved and unchanged. Dashboard owners review scope and acceptance criteria. AI restatement is not approval and cannot broaden the metric catalogue. **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 2 — Map approved metrics to source fields and SQL stages **Prompt** SQL Analysis Plan Prompt **Instructions** Use Codex externally in the authorized workspace. Inspect schemas, lineage, saved queries and repository instructions before drafting the source-field map, join/cardinality plan and SQL-stage blueprint. Preserve step 1 approved semantics. Default to planning; do not execute SQL, connect to a database or edit files without explicit source-permitted authority. Proposed validation queries remain Not executed unless results exist. Record gaps, fanout risks, time boundaries and cost/access limits. Paste the actual external result into Workplace and choose Record external result. **Input for this step** Carry the reviewed specification and metric contracts. Add exact SQL dialect, schemas, table/field evidence, lineage, sanitized samples, reporting windows and permitted read-only/test scope. Supply the source Prompt fields: Analysis goal or decision; SQL dialect and platform; Schema and relationships; Metric definitions and grain; Filters and reporting window; Constraints and source materials. Keep absent information explicit; do not invent values. **Carry forward** Edit and approve the evidenced source-field map, query-stage plan, proposed validation queries, unresolved mappings and authorized implementation boundary. Pass these to implementation without treating planned queries as results. **Review note** Data and metric owners review mappings, grain, joins, time semantics and reconciliation targets. Missing or conflicting fields, unsafe access or potentially costly queries require resolution before dependent implementation. **Prompt ID** AMO-P-000057 **Prompt URL** https://amo.ng/prompts/sql-analysis-plan-prompt **Prompt content** Create an execution-ready SQL analysis plan for the following request. Inputs - Analysis goal or decision: [Analysis goal or decision] - SQL dialect and platform: [SQL dialect and platform] - Schema and relationships: [Schema and relationships] - Metric definitions and grain: [Metric definitions and grain] - Filters and reporting window: [Filters and reporting window] - Constraints and source materials: [Constraints and source materials] Input requirements Treat the analysis goal, SQL dialect, target result grain, relevant tables or schema, metric definitions, and reporting window as minimum inputs. Table DDL, data dictionaries, existing queries, lineage notes, sample rows, query plans, row counts, and known data-quality issues are useful supporting evidence. If a missing detail could change the metric meaning, result grain, join cardinality, population, time boundary, or privacy treatment, ask a focused blocking question before finalizing the plan. If bounded progress is still safe, continue with alternatives and mark the affected decisions as unresolved. Do not invent tables, columns, keys, relationships, business definitions, row counts, query results, or platform capabilities. Codex operating boundaries - Inspect only files, schemas, queries, logs, and other materials supplied in the prompt or actually available in the Codex workspace. - State which materials were inspected and which referenced materials were unavailable. - Default to planning and drafting SQL. Do not connect to a database, modify files, execute SQL, or claim query results unless that access is explicitly available and the user has authorized the action. - Never execute INSERT, UPDATE, DELETE, MERGE, TRUNCATE, DROP, ALTER, DDL, data exports, or production commands as part of this planning task. - Even when execution is authorized, use read-only, non-production access unless a human explicitly approves otherwise. Apply platform controls such as row limits, partition filters, timeouts, dry runs, or cost estimates where available. Use EXPLAIN without runtime analysis by default. - Stop and request human review before handling exposed credentials, unrestricted personal data, regulated data, ambiguous access rights, potentially expensive full scans, or any request that could change production data. Evidence rules Classify important statements as one of: supplied fact, observed in an inspected artifact, assumption, hypothesis, conflict, unknown, or execution evidence. Cite the relevant file, schema object, query, log, or user-provided definition when possible. A proposed validation query is not execution evidence. Report an actual value only when captured output is available, and keep planned, drafted, executed, passed, failed, blocked, and unverified states distinct. Planning workflow 1. Translate the request into a measurable question. Define the output grain, population, dimensions, measures, comparison basis, reporting timezone, date boundaries, and required columns. 2. Build a source map. For each required field, identify the candidate table and column, source grain, key, freshness expectation, nullable behavior, and evidence. Mark unsupported mappings rather than fabricating them. 3. Resolve metric semantics. Specify numerator, denominator, inclusions, exclusions, distinctness rules, null handling, status logic, currency or unit treatment, and whether late-arriving or corrected records can restate results. 4. Design the join graph. State the join keys, join type, expected relationship such as one-to-one or many-to-one, temporal conditions, and the intended handling of unmatched rows. Identify many-to-many paths, slowly changing dimensions, duplicate keys, bridge tables, and fanout risks. 5. Define filtering and time logic. Separate source-reduction filters from business filters. Address inclusive versus exclusive boundaries, timezone conversion, event time versus processing time, partition pruning, snapshot dates, and parameterization. Never interpolate untrusted values directly into SQL. 6. Design the query in stages. Provide a named CTE or subquery map showing each stage's purpose, input grain, output grain, transformations, filters, and join dependencies. Recommend pre-aggregation or deduplication where needed to preserve grain. 7. Draft a dialect-appropriate SQL skeleton when the supplied schema is sufficient. Use only evidenced identifiers. Mark unresolved identifiers or logic in comments; if schema evidence is insufficient, provide structured pseudocode instead of pretending the SQL is runnable. 8. Assess correctness, privacy, security, and performance risks. Consider duplicate facts, null keys, orphan records, fanout, divide-by-zero, integer division, floating-point or currency precision, inconsistent status histories, late data, skew, full scans, non-sargable predicates, sensitive columns, row-level access rules, and accidental disclosure through small groups. 9. Create validation queries. Include checks for source and stage row counts, key uniqueness, null rates, orphan joins, pre-join and post-join cardinality, fanout ratios, duplicate result rows, reconciliation to an independent control total, filter boundaries, known examples, and expected empty or edge cases. Add dry-run, EXPLAIN, or scan-cost checks when supported by the named platform. 10. Define acceptance and handoff. For every validation, provide the expected observation, actual observation if execution evidence exists, evidence reference, status, and action on failure. Identify decisions requiring a data owner, metric owner, privacy reviewer, database administrator, or cost approver. Required deliverable Return the following sections: 1. Analysis specification - Decision or question - Result grain and primary key candidate - Population, measures, dimensions, reporting window, timezone, and output columns - Explicit exclusions and unresolved semantic decisions 2. Evidence and assumption ledger A table with: ID, statement, classification, evidence reference, confidence, impact if wrong, and resolution owner. 3. Source-field map A table with: required concept, table, column or expression, source grain, key or relationship, freshness, null behavior, sensitivity, and status. 4. Join and cardinality plan A table with: left source, right source, join keys, join type, expected cardinality, temporal condition, unmatched-row policy, fanout control, and validation query ID. 5. Metric and filter specification For each metric, show its formula, numerator, denominator, aggregation, distinctness, null and zero handling, units, inclusions, exclusions, and time semantics. List parameters separately from hard-coded filters. 6. Query-stage blueprint A table with: stage name, purpose, inputs, input grain, transformation, output grain, and dependencies. Follow it with the SQL skeleton or marked pseudocode. 7. Validation matrix and validation SQL A table with: check ID, risk tested, validation query, expected observation or threshold, actual observation, evidence, status, and failure response. Use “not executed” for actual observations when no execution occurred. 8. Risk and control register Cover correctness, data quality, privacy, security, performance, and operational risks. For each, provide likelihood, impact, prevention, detection, stop condition, and required approver. 9. Execution handoff List the recommended read-only execution order, required permissions, safe environment, parameters, resource controls, review owners, unresolved blockers, and rollback or recovery guidance. For this read-only analysis, recovery should focus on cancelling expensive work, removing unsafe temporary artifacts, and preserving prior published outputs until validation passes. Do not describe the analysis as tested, verified, approved, production-ready, or complete unless the corresponding action occurred and supporting evidence is present. End with the smallest safe next action and the person or role responsible for it. ## Step 3 — Implement the approved dashboard in an authorized workspace **Prompt** Build an Internal Operations Dashboard from Approved Metrics **Instructions** Use Codex externally to implement the approved dashboard in the supplied repository and safe test environment. Inspect before editing; preserve unrelated work, approved definitions and access boundaries. Make only authorized changes. Connect components to metric IDs and retain loading, empty, stale, partial, no-access and error states. Test authorized paths and prepare a reversible change manifest. Never deploy, enable production refresh, modify source-system data or present fixtures as production evidence. Return Partial or Blocked when implementation is unavailable. Record the actual external result in Workplace. **Input for this step** Supply the reviewed requirements and query/source mapping, contracts, authorized repository/test context, roles/access rules, acceptance criteria and release restrictions. Supply the source Prompt fields: approved_metric_contracts; repository_and_data_context; roles_and_access_rules; dashboard_requirements; acceptance_criteria_and_authorized_scope. Keep absent information explicit; do not invent values. **Carry forward** Human-review and edit the implementation manifest, exact query artifacts, source/fixture references, tests actually run, component mapping, unresolved defects and rollback instructions. Carry only supported implementation evidence into reconciliation. **Review note** Technical, data and access owners review the actual diff and test evidence. A proposal, passing fixture or polished interface does not prove deployed correctness. Stop for authorization, privacy, metric-conflict or unresolved access failures. **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 — Reconcile implemented queries and dashboard results **Prompt** AI-Generated SQL Result Verification and Reconciliation **Instructions** Use Codex externally to inspect the exact implemented SQL and claimed dashboard results against unchanged contracts and authoritative comparison evidence. Review semantics and reproducibility before accepting figures. Run only authorized safe checks; record SQL, parameters, periods, source scope and results. Investigate variance causes before a minimal justified correction. Preserve access and downstream output boundaries. Missing execution/comparison evidence remains Unverified; invent no tolerance. Patches require retest evidence. Record the actual external result in Workplace. **Input for this step** Carry the change manifest, exact queries, observed results, approved definitions and periods, control totals, supplied materiality/tolerances, safe workspace constraints and authorized verification commands. Supply the source Prompt fields: Repository scope and task; Relevant files and instructions; Observed evidence; Constraints and authorized changes; Environment details without secrets; Verification commands and acceptance criteria. Keep absent information explicit; do not invent values. **Carry forward** Edit and approve the query-intent contract, semantic-review and reconciliation tables, corrections with retests, unsupported-result register and owner acceptance requirements. Pass unresolved variances and unrun checks intact to release review. **Review note** An accountable data/analytics owner reviews reconciliation scope and evidence; finance reviews financial measures where applicable. Static review or fixture agreement does not establish production accuracy. Material unsupported results stay excluded from decision use. **Prompt ID** AMO-P-000287 **Prompt URL** https://amo.ng/prompts/ai-generated-sql-result-verification-and-reconciliation **Prompt content** Verify the AI-generated SQL and its claimed result before anyone relies on it for the stated decision. Treat this as a defensible review artifact, not a general SQL improvement exercise. Context to provide: - Repository scope and task: [Repository scope and task] - Relevant files and instructions: [Relevant files and instructions] - Observed evidence: [Observed evidence] - Constraints and authorized changes: [Constraints and authorized changes] - Environment details without secrets: [Environment details without secrets] - Verification commands and acceptance criteria: [Verification commands and acceptance criteria] Working rules: 1. Inspect the relevant files, saved queries, schemas, models, tests, lineage notes, and query artifacts first where they are available. 2. Do not claim that a table, file, source, command, test, query execution, permission boundary, or approval was inspected unless there is direct evidence in the provided materials or accessible workspace. 3. Identify the likely root cause of any discrepancy before editing SQL or proposing a corrected query. 4. Apply the smallest safe change needed to correct the query. Preserve existing intended behavior unless the evidence shows it is wrong. 5. Avoid broad rewrites, style-only edits, or migration to a different modeling pattern unless required to remove a proven defect. 6. Distinguish observations from inference. Mark unsupported assumptions explicitly. 7. Respect access boundaries. Do not suggest bypassing row-level security, protected schemas, production safeguards, or data owner controls. 8. Run syntax checks, query compilation, dry runs, unit tests, dbt tests, warehouse explain plans, or limited validation queries where available and appropriate. If execution is unavailable, state exactly what could not be run and what evidence substitutes for it. 9. Do not present a corrected result as final unless it is reproducible from inspected SQL and accessible evidence. Missing-input gate: - Treat the exact SQL, intended metric or decision and grain, relevant schema or lineage, and comparison source or acceptance threshold as blocking when their absence or conflict prevents semantic review or reconciliation. Request all blocking items in one consolidated clarification and stop the affected conclusion until they are supplied. - Continue with non-blocking gaps only as explicit Unknowns with their decision impact. Review procedure: A. Build the query intent contract - Restate the decision or metric question in operational terms. - Define the expected grain of the result. - Identify required dimensions, filters, joins, exclusions, deduplication rules, aggregation logic, time window, timezone, and freshness expectations. - Identify the authoritative definition owner when evident, such as data owner, analytics owner, finance owner, product owner, or compliance owner. - List evidence supplied versus evidence missing. B. Review SQL semantics before result claims - Check whether selected columns, grouping, joins, filters, CTEs, window functions, null handling, distinct logic, and aggregation match the query intent contract. - Check for join multiplication, accidental inner joins, incomplete predicates, slowly changing dimension issues, many-to-many joins, late-arriving data, timezone drift, partition filters, and snapshot-versus-current-state confusion. - Check whether access constraints or row-level filters could change the observed result. - Identify whether the SQL answers the stated question, a narrower question, a broader question, or a different question. C. Review execution and reproducibility evidence - Determine whether the claimed result can be traced to a specific SQL text, execution environment, parameters, source versions, run time, and data freshness state. - If query execution is available, run the safest reproducible check permitted by the environment and record the command/query used, result shape, row counts, and relevant totals. - If execution is not available, perform static validation and specify the minimum evidence needed from the data owner or analytics owner to complete reconciliation. D. Reconcile against authoritative totals - Compare the claimed result to authoritative totals, source-of-truth reports, known control totals, prior certified extracts, ledger totals, or approved metric definitions where supplied. - Reconcile at the most useful level: total, time bucket, segment, source system, account, customer, product, or other relevant dimension. - Explain every material variance using evidence where possible. Separate confirmed causes from plausible causes. E. Correct only what is justified - If the SQL is wrong and enough evidence exists, provide a corrected query or minimal patch. - If there is not enough evidence to correct the query safely, provide a bounded correction proposal and list the exact evidence required before use. - Preserve naming, output shape, filters, permissions, and downstream expectations unless the discrepancy requires a specific change. Deliverable format: 1. Query intent contract - Decision or metric question: - Intended grain: - Required population and exclusions: - Required time logic and timezone: - Required joins and source precedence: - Authoritative definitions or totals used: - Accountable owner to verify final use: - Missing context that limits certainty: 2. Semantic and execution review Create a table with columns: - Review area - Evidence inspected - Observation - Risk to claimed result - Status: Pass / Fail / Unverified - Notes or required follow-up Include at minimum: grain, joins, filters, aggregation, deduplication, time logic, null handling, access boundaries, source freshness, result reproducibility, and output shape. 3. Reconciliation table Create a table with columns: - Reconciliation item - AI-claimed value - Verified or control value - Difference - Materiality assessment - Evidence source - Explanation - Status: Reconciled / Variance explained / Unresolved 4. Unsupported-result register Create a table with columns: - Unsupported claim or result component - Why it is unsupported - Evidence needed - Accountable owner or source to confirm - Decision impact 5. Corrected-query and acceptance record - Root cause summary before any SQL change: - Minimal corrected SQL or patch, if justified: - Behavior intentionally preserved: - Behavior intentionally changed: - Files changed, if any: - Syntax checks, tests, dry runs, or executions performed: - Verification results: - Remaining uncertainty: - Acceptance decision: Accept / Accept with caveats / Reject / Cannot determine - Acceptance criteria met or unmet: - Owner verification required before decision use: Completion check: - The claimed result is either reconciled, corrected and reproducible, or explicitly rejected as unsupported. - All material assumptions are labeled. - Any changed files are summarized. - Verification results and unavailable checks are stated plainly. - The final acceptance decision is tied to the acceptance threshold or materiality standard. ## Step 5 — Review dashboard trust and the release handoff **Prompt** Business KPI Dashboard Trust and Definition Audit **Instructions** Run the source Prompt in ChatGPT to review the implemented dashboard and supplied evidence. Compare approved definitions with actual calculations, lineage, filters, freshness, access, reconciliation and ownership. Preserve its trust statuses and evidence limits; successful refresh is not proof of accuracy. Review monitoring, disablement and rollback handoff. Produce decision-use restrictions and a release recommendation for accountable humans. Do not redefine metrics, approve targets, publish a dashboard or claim unseen tests were performed. **Input for this step** Supply dashboard screenshots/export, unchanged contracts, implementation/reconciliation records, exact filters/periods, refresh evidence, owners, conflicts, access tests and allowed-change boundary. Production release is outside this step. Supply the source Prompt fields: 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. Keep absent information explicit; do not invent values. **Carry forward** Edit the metric trust register, unresolved issues, release/hold decision record, decision-use caveats, monitoring and rollback handoff. Complete after accountable owners record their decision and restrictions; do not imply release occurred. **Review note** Metric/data owners and the release owner make the decision. Material definition, lineage, access, freshness or reconciliation gaps require a hold on affected use. AI recommendations, Workflow completion and Run Records are not approval or certification. **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 - Every metric retains its approved meaning; definition or target changes return to the accountable owner outside this Workflow. - Source-field, grain, join, time and dashboard mappings are traceable; proposed checks remain distinct from executed results. - Implementation and query verification have attributable evidence, including access restrictions, stale/error states and reconciliation to approved totals. Unrun checks and material variances remain visible and block affected decision use. - Humans review every step before editable carry-forward advances. Codex work occurs externally in the authorized repository and is recorded as an external result; a chat provider is never substituted. - The final record states an accountable release decision or hold, residual restrictions, remediation, monitoring and rollback responsibilities. A hold completes the review record but does not authorize release. - No step publishes a dashboard, enables production refresh, automates recurring reports, changes approved formulas or grants production access. # Build a Governed KPI Dashboard from Approved Metric Definitions Workflow ID: AMO-W-000042 Workflow URL: https://amo.ng/workflows/build-a-governed-kpi-dashboard-from-approved-metric-definitions Use this Amo.ng workflow with your preferred AI tool. Complete the steps in order and carry the specified output forward. Outcome: A dashboard change set and release-review record tracing each approved metric through source fields, query stages, dashboard components and reconciliation evidence. Includes access and data-state tests, unresolved variances, decision-use restrictions, monitoring and rollback handoff. Publication or deployment is a separate authorized action. Required inputs: - Already-approved metric contracts with stable IDs, formulas, grain, population, exclusions, units, time rules, owners and approval evidence. Bring approved targets and tolerances where applicable; unresolved definitions block affected metrics. - Approved dashboard decisions, audience, views and boundaries; source-of-record designations and authoritative control totals for matching periods and populations. - SQL dialect, schema or data dictionary, lineage, source-field evidence, existing queries and sanitized fixtures or authorized read-only results. - Authorized repository and test environment, existing working-tree changes, allowed files/actions and access/tenant/privacy rules. Never supply production credentials or unnecessary personal data. - Acceptance criteria, permitted test scope, freshness/performance expectations, release authority, monitoring responsibilities and rollback controls. - Start after metric approval. Use the separate operations-dashboard/reporting journey when metric-definition governance or recurring report automation is required. ## Step 1 — Confirm approved metric inputs and dashboard requirements **Instructions** Run the source Prompt in ChatGPT with the already-approved metric catalogue and dashboard decision brief. Treat its KPI dictionary as a faithful restatement of supplied approved contracts, not a new metric-design exercise. Preserve formula, grain, population, exclusions, time logic, targets and approval references exactly. Map approved metrics to dashboard views, interactions, access and acceptance evidence. Record missing or conflicting approval/source details as blockers; do not invent definitions or targets. Produce the dashboard specification and evidence-gap register. **Input for this step** Provide approved contracts, decision/users brief, dashboard artifacts, source inventory, access requirements and acceptance criteria. Scope is dashboard implementation only; subscriptions, scheduled reporting and external delivery remain excluded. Supply the source Prompt fields: Dashboard objective and scope; Users and decisions; Metric definitions and targets; Data sources and constraints; Interaction and delivery needs; Governance and operational constraints; Existing artifacts and acceptance criteria. Keep absent information explicit; do not invent values. **Carry forward** After metric and dashboard owners review, edit and approve the scope, unchanged metric dictionary, component requirements, access boundaries and unresolved-input register. Complete only when the intake decision is recorded; blocked metrics do not advance to implementation. **Review note** Metric owners confirm the contracts are approved and unchanged. Dashboard owners review scope and acceptance criteria. AI restatement is not approval and cannot broaden the metric catalogue. **Prompt** Dashboard Requirements Specification Prompt **Prompt ID** AMO-P-000058 **Prompt URL** https://amo.ng/prompts/dashboard-requirements-prompt ## Step 2 — Map approved metrics to source fields and SQL stages **Instructions** Use Codex externally in the authorized workspace. Inspect schemas, lineage, saved queries and repository instructions before drafting the source-field map, join/cardinality plan and SQL-stage blueprint. Preserve step 1 approved semantics. Default to planning; do not execute SQL, connect to a database or edit files without explicit source-permitted authority. Proposed validation queries remain Not executed unless results exist. Record gaps, fanout risks, time boundaries and cost/access limits. Paste the actual external result into Workplace and choose Record external result. **Input for this step** Carry the reviewed specification and metric contracts. Add exact SQL dialect, schemas, table/field evidence, lineage, sanitized samples, reporting windows and permitted read-only/test scope. Supply the source Prompt fields: Analysis goal or decision; SQL dialect and platform; Schema and relationships; Metric definitions and grain; Filters and reporting window; Constraints and source materials. Keep absent information explicit; do not invent values. **Carry forward** Edit and approve the evidenced source-field map, query-stage plan, proposed validation queries, unresolved mappings and authorized implementation boundary. Pass these to implementation without treating planned queries as results. **Review note** Data and metric owners review mappings, grain, joins, time semantics and reconciliation targets. Missing or conflicting fields, unsafe access or potentially costly queries require resolution before dependent implementation. **Prompt** SQL Analysis Plan Prompt **Prompt ID** AMO-P-000057 **Prompt URL** https://amo.ng/prompts/sql-analysis-plan-prompt ## Step 3 — Implement the approved dashboard in an authorized workspace **Instructions** Use Codex externally to implement the approved dashboard in the supplied repository and safe test environment. Inspect before editing; preserve unrelated work, approved definitions and access boundaries. Make only authorized changes. Connect components to metric IDs and retain loading, empty, stale, partial, no-access and error states. Test authorized paths and prepare a reversible change manifest. Never deploy, enable production refresh, modify source-system data or present fixtures as production evidence. Return Partial or Blocked when implementation is unavailable. Record the actual external result in Workplace. **Input for this step** Supply the reviewed requirements and query/source mapping, contracts, authorized repository/test context, roles/access rules, acceptance criteria and release restrictions. Supply the source Prompt fields: approved_metric_contracts; repository_and_data_context; roles_and_access_rules; dashboard_requirements; acceptance_criteria_and_authorized_scope. Keep absent information explicit; do not invent values. **Carry forward** Human-review and edit the implementation manifest, exact query artifacts, source/fixture references, tests actually run, component mapping, unresolved defects and rollback instructions. Carry only supported implementation evidence into reconciliation. **Review note** Technical, data and access owners review the actual diff and test evidence. A proposal, passing fixture or polished interface does not prove deployed correctness. Stop for authorization, privacy, metric-conflict or unresolved access failures. **Prompt** Build an Internal Operations Dashboard from Approved Metrics **Prompt ID** AMO-P-000341 **Prompt URL** https://amo.ng/prompts/build-internal-operations-dashboard-approved-metrics ## Step 4 — Reconcile implemented queries and dashboard results **Instructions** Use Codex externally to inspect the exact implemented SQL and claimed dashboard results against unchanged contracts and authoritative comparison evidence. Review semantics and reproducibility before accepting figures. Run only authorized safe checks; record SQL, parameters, periods, source scope and results. Investigate variance causes before a minimal justified correction. Preserve access and downstream output boundaries. Missing execution/comparison evidence remains Unverified; invent no tolerance. Patches require retest evidence. Record the actual external result in Workplace. **Input for this step** Carry the change manifest, exact queries, observed results, approved definitions and periods, control totals, supplied materiality/tolerances, safe workspace constraints and authorized verification commands. Supply the source Prompt fields: Repository scope and task; Relevant files and instructions; Observed evidence; Constraints and authorized changes; Environment details without secrets; Verification commands and acceptance criteria. Keep absent information explicit; do not invent values. **Carry forward** Edit and approve the query-intent contract, semantic-review and reconciliation tables, corrections with retests, unsupported-result register and owner acceptance requirements. Pass unresolved variances and unrun checks intact to release review. **Review note** An accountable data/analytics owner reviews reconciliation scope and evidence; finance reviews financial measures where applicable. Static review or fixture agreement does not establish production accuracy. Material unsupported results stay excluded from decision use. **Prompt** AI-Generated SQL Result Verification and Reconciliation **Prompt ID** AMO-P-000287 **Prompt URL** https://amo.ng/prompts/ai-generated-sql-result-verification-and-reconciliation ## Step 5 — Review dashboard trust and the release handoff **Instructions** Run the source Prompt in ChatGPT to review the implemented dashboard and supplied evidence. Compare approved definitions with actual calculations, lineage, filters, freshness, access, reconciliation and ownership. Preserve its trust statuses and evidence limits; successful refresh is not proof of accuracy. Review monitoring, disablement and rollback handoff. Produce decision-use restrictions and a release recommendation for accountable humans. Do not redefine metrics, approve targets, publish a dashboard or claim unseen tests were performed. **Input for this step** Supply dashboard screenshots/export, unchanged contracts, implementation/reconciliation records, exact filters/periods, refresh evidence, owners, conflicts, access tests and allowed-change boundary. Production release is outside this step. Supply the source Prompt fields: 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. Keep absent information explicit; do not invent values. **Carry forward** Edit the metric trust register, unresolved issues, release/hold decision record, decision-use caveats, monitoring and rollback handoff. Complete after accountable owners record their decision and restrictions; do not imply release occurred. **Review note** Metric/data owners and the release owner make the decision. Material definition, lineage, access, freshness or reconciliation gaps require a hold on affected use. AI recommendations, Workflow completion and Run Records are not approval or certification. **Prompt** Business KPI Dashboard Trust and Definition Audit **Prompt ID** AMO-P-000228 **Prompt URL** https://amo.ng/prompts/business-kpi-dashboard-trust-definition-audit Completion criteria: - Every metric retains its approved meaning; definition or target changes return to the accountable owner outside this Workflow. - Source-field, grain, join, time and dashboard mappings are traceable; proposed checks remain distinct from executed results. - Implementation and query verification have attributable evidence, including access restrictions, stale/error states and reconciliation to approved totals. Unrun checks and material variances remain visible and block affected decision use. - Humans review every step before editable carry-forward advances. Codex work occurs externally in the authorized repository and is recorded as an external result; a chat provider is never substituted. - The final record states an accountable release decision or hold, residual restrictions, remediation, monitoring and rollback responsibilities. A hold completes the review record but does not authorize release. - No step publishes a dashboard, enables production refresh, automates recurring reports, changes approved formulas or grants production access.Copy Workflow copies all steps and their linked Prompt instructions. Use with AI copies a shorter guide with links to the source Prompts. Both actions only copy text. Run this Workflow in Workplace opens the guided Workflow Runner for supported steps.
Outcome
A dashboard change set and release-review record tracing each approved metric through source fields, query stages, dashboard components and reconciliation evidence. Includes access and data-state tests, unresolved variances, decision-use restrictions, monitoring and rollback handoff. Publication or deployment is a separate authorized action.
Before you begin
Gather the required inputs before starting. Keep missing information visible and follow each step’s review guidance before continuing.
- Already-approved metric contracts with stable IDs, formulas, grain, population, exclusions, units, time rules, owners and approval evidence. Bring approved targets and tolerances where applicable; unresolved definitions block affected metrics.
- Approved dashboard decisions, audience, views and boundaries; source-of-record designations and authoritative control totals for matching periods and populations.
- SQL dialect, schema or data dictionary, lineage, source-field evidence, existing queries and sanitized fixtures or authorized read-only results.
- Authorized repository and test environment, existing working-tree changes, allowed files/actions and access/tenant/privacy rules. Never supply production credentials or unnecessary personal data.
- Acceptance criteria, permitted test scope, freshness/performance expectations, release authority, monitoring responsibilities and rollback controls.
- Start after metric approval. Use the separate operations-dashboard/reporting journey when metric-definition governance or recurring report automation is required.
Ordered sequence
Workflow steps
Complete the steps in order. Review each result before carrying approved information into the next step. Some steps can run in Workplace; manual or external steps remain clearly identified.
-
Step 1 Confirm approved metric inputs and dashboard requirements
Run the source Prompt in ChatGPT with the already-approved metric catalogue and dashboard decision brief. Treat its KPI dictionary as a faithful restatement of supplied approved contracts, not a new metric-design exercise. Preserve formula, grain, population, exclusions, time logic, targets and approval references exactly. Map approved metrics to dashboard views, interactions, access and acceptance evidence. Record missing or conflicting approval/source details as blockers; do not invent definitions or targets. Produce the dashboard specification and evidence-gap register.
Prompt: Dashboard Requirements Specification PromptInput for this step
Provide approved contracts, decision/users brief, dashboard artifacts, source inventory, access requirements and acceptance criteria. Scope is dashboard implementation only; subscriptions, scheduled reporting and external delivery remain excluded. Supply the source Prompt fields: Dashboard objective and scope; Users and decisions; Metric definitions and targets; Data sources and constraints; Interaction and delivery needs; Governance and operational constraints; Existing artifacts and acceptance criteria. Keep absent information explicit; do not invent values.
Carry forward
After metric and dashboard owners review, edit and approve the scope, unchanged metric dictionary, component requirements, access boundaries and unresolved-input register. Complete only when the intake decision is recorded; blocked metrics do not advance to implementation.
Review note
Metric owners confirm the contracts are approved and unchanged. Dashboard owners review scope and acceptance criteria. AI restatement is not approval and cannot broaden the metric catalogue.
-
Step 2 Map approved metrics to source fields and SQL stages
Use Codex externally in the authorized workspace. Inspect schemas, lineage, saved queries and repository instructions before drafting the source-field map, join/cardinality plan and SQL-stage blueprint. Preserve step 1 approved semantics. Default to planning; do not execute SQL, connect to a database or edit files without explicit source-permitted authority. Proposed validation queries remain Not executed unless results exist. Record gaps, fanout risks, time boundaries and cost/access limits. Paste the actual external result into Workplace and choose Record external result.
Prompt: SQL Analysis Plan PromptInput for this step
Carry the reviewed specification and metric contracts. Add exact SQL dialect, schemas, table/field evidence, lineage, sanitized samples, reporting windows and permitted read-only/test scope. Supply the source Prompt fields: Analysis goal or decision; SQL dialect and platform; Schema and relationships; Metric definitions and grain; Filters and reporting window; Constraints and source materials. Keep absent information explicit; do not invent values.
Carry forward
Edit and approve the evidenced source-field map, query-stage plan, proposed validation queries, unresolved mappings and authorized implementation boundary. Pass these to implementation without treating planned queries as results.
Review note
Data and metric owners review mappings, grain, joins, time semantics and reconciliation targets. Missing or conflicting fields, unsafe access or potentially costly queries require resolution before dependent implementation.
-
Step 3 Implement the approved dashboard in an authorized workspace
Use Codex externally to implement the approved dashboard in the supplied repository and safe test environment. Inspect before editing; preserve unrelated work, approved definitions and access boundaries. Make only authorized changes. Connect components to metric IDs and retain loading, empty, stale, partial, no-access and error states. Test authorized paths and prepare a reversible change manifest. Never deploy, enable production refresh, modify source-system data or present fixtures as production evidence. Return Partial or Blocked when implementation is unavailable. Record the actual external result in Workplace.
Prompt: Build an Internal Operations Dashboard from Approved MetricsInput for this step
Supply the reviewed requirements and query/source mapping, contracts, authorized repository/test context, roles/access rules, acceptance criteria and release restrictions. Supply the source Prompt fields: approved_metric_contracts; repository_and_data_context; roles_and_access_rules; dashboard_requirements; acceptance_criteria_and_authorized_scope. Keep absent information explicit; do not invent values.
Carry forward
Human-review and edit the implementation manifest, exact query artifacts, source/fixture references, tests actually run, component mapping, unresolved defects and rollback instructions. Carry only supported implementation evidence into reconciliation.
Review note
Technical, data and access owners review the actual diff and test evidence. A proposal, passing fixture or polished interface does not prove deployed correctness. Stop for authorization, privacy, metric-conflict or unresolved access failures.
-
Step 4 Reconcile implemented queries and dashboard results
Use Codex externally to inspect the exact implemented SQL and claimed dashboard results against unchanged contracts and authoritative comparison evidence. Review semantics and reproducibility before accepting figures. Run only authorized safe checks; record SQL, parameters, periods, source scope and results. Investigate variance causes before a minimal justified correction. Preserve access and downstream output boundaries. Missing execution/comparison evidence remains Unverified; invent no tolerance. Patches require retest evidence. Record the actual external result in Workplace.
Prompt: AI-Generated SQL Result Verification and ReconciliationInput for this step
Carry the change manifest, exact queries, observed results, approved definitions and periods, control totals, supplied materiality/tolerances, safe workspace constraints and authorized verification commands. Supply the source Prompt fields: Repository scope and task; Relevant files and instructions; Observed evidence; Constraints and authorized changes; Environment details without secrets; Verification commands and acceptance criteria. Keep absent information explicit; do not invent values.
Carry forward
Edit and approve the query-intent contract, semantic-review and reconciliation tables, corrections with retests, unsupported-result register and owner acceptance requirements. Pass unresolved variances and unrun checks intact to release review.
Review note
An accountable data/analytics owner reviews reconciliation scope and evidence; finance reviews financial measures where applicable. Static review or fixture agreement does not establish production accuracy. Material unsupported results stay excluded from decision use.
-
Step 5 Review dashboard trust and the release handoff
Run the source Prompt in ChatGPT to review the implemented dashboard and supplied evidence. Compare approved definitions with actual calculations, lineage, filters, freshness, access, reconciliation and ownership. Preserve its trust statuses and evidence limits; successful refresh is not proof of accuracy. Review monitoring, disablement and rollback handoff. Produce decision-use restrictions and a release recommendation for accountable humans. Do not redefine metrics, approve targets, publish a dashboard or claim unseen tests were performed.
Prompt: Business KPI Dashboard Trust and Definition AuditInput for this step
Supply dashboard screenshots/export, unchanged contracts, implementation/reconciliation records, exact filters/periods, refresh evidence, owners, conflicts, access tests and allowed-change boundary. Production release is outside this step. Supply the source Prompt fields: 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. Keep absent information explicit; do not invent values.
Carry forward
Edit the metric trust register, unresolved issues, release/hold decision record, decision-use caveats, monitoring and rollback handoff. Complete after accountable owners record their decision and restrictions; do not imply release occurred.
Review note
Metric/data owners and the release owner make the decision. Material definition, lineage, access, freshness or reconciliation gaps require a hold on affected use. AI recommendations, Workflow completion and Run Records are not approval or certification.
Completion criteria
- Every metric retains its approved meaning; definition or target changes return to the accountable owner outside this Workflow.
- Source-field, grain, join, time and dashboard mappings are traceable; proposed checks remain distinct from executed results.
- Implementation and query verification have attributable evidence, including access restrictions, stale/error states and reconciliation to approved totals. Unrun checks and material variances remain visible and block affected decision use.
- Humans review every step before editable carry-forward advances. Codex work occurs externally in the authorized repository and is recorded as an external result; a chat provider is never substituted.
- The final record states an accountable release decision or hold, residual restrictions, remediation, monitoring and rollback responsibilities. A hold completes the review record but does not authorize release.
- No step publishes a dashboard, enables production refresh, automates recurring reports, changes approved formulas or grants production access.
Was this useful?
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.
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.