# Build an Internal Operations Dashboard from Approved Metrics

Amo ID: AMO-P-000341
Version: 1.0.0
Public URL: https://amo.ng/prompts/build-internal-operations-dashboard-approved-metrics

Summary: Implement an internal operations dashboard from approved metric contracts, with source reconciliation, enforced access rules, observable data states, performance evidence, and a reversible release handoff.

Use this for: Use this for turning approved metric contracts and dashboard requirements into a tested internal dashboard implementation without redefining business metrics or publishing it.

Category: Codex & Coding
Tool: Codex
Difficulty: Expert
Prompt type: feature build

## Best Use Cases

1. Implementing an internal dashboard after metric definitions have been approved
2. Connecting governed operational metrics to existing application components
3. Adding role-aware filters, freshness indicators, and failure states
4. Preparing a reversible dashboard release for data-owner review

## Prompt Body

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.

## Variables to Replace

1. approved_metric_contracts
2. repository_and_data_context
3. roles_and_access_rules
4. dashboard_requirements
5. acceptance_criteria_and_authorized_scope

## How to Use

Open Codex in the target repository or provide a complete repository snapshot. Replace all five variables with the approved metric contracts, repository and sanitized data context, role and access rules, dashboard requirements, and exact acceptance criteria and permissions. Provide schemas, data dictionaries, approved calculations, existing queries, authorized fixtures, relevant source files, and permitted verification commands. Do not provide production credentials or unnecessary personal data. Review Codex's metric-to-component checkpoint before authorizing edits, then have the metric owner, data owner, security reviewer, and release owner examine the diff, reconciliation evidence, access tests, and rollback plan before any separate production activation.

## Example Use Case

An operations team has approved metric contracts for backlog size, first-response time, breach rate, and resolution throughput. A Laravel repository, sanitized fixtures, role definitions, and dashboard acceptance criteria are available in an isolated worktree. The Prompt directs Codex to implement the protected route, queries, filters, freshness state, dashboard components, and authorized CSV export; reconcile fixture totals; test timezone boundaries, stale data, unauthorized roles, errors, query budgets, and accessibility; and leave the feature disabled for release-owner review.

## Tags

1. Codex & Coding
2. feature-build
3. dashboard
4. dashboard-requirements
5. metric-definitions
6. data-analysis
7. analytics
8. data-quality
9. access-control

## Dates

Published: 2026-09-09
Updated: 2026-09-09