Automate KPI Reporting from Approved Metric Definitions

Implement a repeatable KPI-reporting process from the approved metric definitions. Work only in the authorized repository and non-production data context supplied in this session. The result must be working code or editable configuration with test evidence, not another metric definition, dashboard brief, audit, or implementation plan.

## Required inputs

Approved metric definitions:
{{approved_metric_definitions}}

Source and repository context:
{{source_and_repository_context}}

Report and output specification:
{{report_and_output_specification}}

Schedule and destination contract:
{{schedule_and_destination_contract}}

Acceptance criteria and authorized scope:
{{acceptance_criteria_and_authorized_scope}}

## Evidence and assumption rules

1. Classify material statements as supplied fact, repository observation, execution evidence, assumption, conflict, missing information, or unresolved uncertainty. Cite file paths, symbols, configuration keys, supplied data-contract sections, and command results where available.
2. Do not invent metric definitions, formulas, owners, source fields, joins, schedules, destinations, tolerances, credentials, data values, command output, test results, or approvals.
3. Treat the approved metric definitions as the calculation authority. If definitions conflict or omit a material grain, formula, inclusion, exclusion, time, currency, unit, or rounding rule, stop the affected metric and request a decision from the data owner. Do not redefine or silently reconcile it.
4. Distinguish sanitized fixture results from observations made against an approved read-only source. Never present fixture output as production evidence.
5. Use only the minimum data needed for implementation and testing. Do not request secrets, credentials, production exports, unnecessary personal data, or confidential values. Refer to connections through environment-variable or credential-reference names, never values.
6. Preserve unrelated repository and configuration changes. Do not reformat, replace, or repair out-of-scope work.

## Authorization boundary

- Implementation requires an editable repository or configuration export, approved metric contracts, a usable output specification, and either sanitized fixtures or an explicitly authorized read-only data source.
- Inspect only the supplied workspace, files, schemas, interfaces, fixtures, and command output. Do not imply access to a source, scheduler, reporting destination, or production environment that is not available in this session.
- You may change only files and configuration within the supplied authorized scope. Keep schedules disabled and external delivery disconnected or directed to an approved test sink.
- Do not mutate source systems, enable a production schedule, send a report, publish an output, change access, make a management decision, install dependencies, run a destructive migration, deploy, merge, commit, or communicate externally unless separately authorized.
- Stop before any irreversible data operation, production connection, external send, secret exposure, destructive command, or change outside the allowed file boundary. State the blocked action, evidence needed, accountable owner, and safest next step.

## Implementation method

### 1. Run the input gate

For every metric, confirm that the supplied contract identifies its stable identifier, business meaning, formula, source, grain, dimensions, inclusions, exclusions, date field, timezone, currency or unit behavior, null treatment, correction or restatement treatment, precision, rounding rule, owner, and reconciliation tolerance where applicable.

Confirm the report structure, period controls, sort order, labels, file or view format, destination, schedule, and acceptance criteria. Record missing or contradictory items. If a missing item could alter a calculation or disclose data, block that metric rather than guessing.

### 2. Inspect the implementation context

Before editing, inspect the repository tree, current working-tree state, framework and runtime, package manifests, relevant source adapters, models or queries, transformation code, report generators, scheduling configuration, delivery adapters, test framework, fixtures, logging, and existing operational documentation.

Identify what is observed, unavailable, or not inspected. Establish the current baseline using only safe, authorized commands. Do not add a dependency when the existing stack can meet the contract.

### 3. Create a concise implementation checkpoint

Map each metric and acceptance criterion to the files, functions, queries, transformations, report sections, fixtures, and tests that will implement it. State the intended changes, protected files, authorized commands, external effects that will remain disabled, and rollback method.

If there is no editable workspace, approved metric contract, safe data interface, or testable output target, stop with a blocked handoff. Do not substitute pseudocode and call the work implemented.

### 4. Implement source extraction safely

Use approved read-only interfaces or sanitized fixtures. Implement explicit source selection, field mapping, filters, join keys, expected cardinality, incremental or full-extract behavior, and watermark or cutoff handling where required.

Validate missing fields, malformed values, duplicates, late records, corrected records, unexpected nulls, and schema changes. Fail visibly when a required source or field is unavailable. Do not update source records as part of reporting.

### 5. Implement transformations and calculations

Implement the approved formulas exactly. Preserve source-to-metric traceability through named transformations, tests, or generated lineage metadata supported by the repository.

Apply the stated grain, dimensions, eligibility rules, dates, timezones, currencies, units, precision, rounding, and restatement behavior. Prevent invalid aggregation, duplicate contribution, divide-by-zero, silent coercion, and implicit timezone or currency conversion. When a metric contract remains unresolved, return an explicit unavailable or blocked state rather than a fabricated value.

### 6. Implement report generation

Generate the approved report shape with stable labels, ordering, period markers, source freshness, generated-at time, unit or currency labels, and data-quality status where specified. Make empty, partial, stale, and failed states distinguishable from a true zero.

Keep output deterministic for identical approved inputs. Normalize ordering and formatting where needed, and avoid volatile values in comparisons unless the contract requires them.

### 7. Implement scheduling and delivery in a disabled state

Represent the approved schedule, timezone, cutoff, destination, retry policy, and ownership in editable configuration, but leave the schedule disabled. Keep external delivery disabled, disconnected, or directed to an approved test sink.

Provide evidence of the disabled state without revealing credential values. Do not send messages, upload reports, publish files, or activate jobs.

### 8. Add rerun, idempotency, and recovery controls

Define a stable run identity and reporting period. Ensure a retry cannot create duplicate outputs or inconsistent partial files. Use atomic output replacement, temporary files, checkpoints, or equivalent repository conventions when appropriate.

Handle extraction failure, transformation failure, report-generation failure, unavailable destinations, and uncertain completion. Preserve enough safe diagnostic evidence to reconcile a failed run. Document how to resume, rerun, quarantine, replace, or roll back an output without changing authoritative source data.

### 9. Reconcile to authoritative supplied totals

For each metric with an approved comparison, reconcile record counts, component totals, final values, period boundaries, and tolerances. Record absolute and relative differences where meaningful. A tolerance pass must use the supplied rule; do not invent one after seeing the result.

Treat unexplained differences as unresolved. Do not force a match through an undocumented filter, adjustment, or overwrite.

### 10. Test domain-specific failure paths

Create and run the narrowest safe tests supported by the repository. Cover, as applicable:

- an approved valid period and expected metric fixture;
- missing, duplicate, late, corrected, and malformed records;
- null, zero, negative, boundary, currency, unit, rounding, and timezone cases;
- invalid joins, unexpected cardinality, schema drift, and unavailable sources;
- empty, partial, stale, and failed report states;
- deterministic output for repeated identical inputs;
- rerun idempotency and recovery after failure between extraction, calculation, generation, and delivery;
- reconciliation within and outside the declared tolerance;
- disabled scheduling and disabled external delivery.

Record each exact command and its exit status. If a test cannot run, mark it not run or blocked and explain why. A successful build is not calculation evidence, and fixture success is not proof about production data.

### 11. Prepare the operational handoff

Describe configuration inputs, schedule and destination enablement steps, required permissions, monitoring signals, reconciliation cadence, data-quality alerts, failure ownership, rerun procedure, output rollback, and post-release checks. Enabling, sending, and release remain actions for the data owner and release owner under their normal change process.

## Stop conditions

Stop with a precise blocked handoff when any of the following applies:

- metric meaning or a material calculation rule is missing or conflicting;
- the repository, editable configuration, approved fixture, or authorized read-only source is unavailable;
- requested access exceeds the supplied authority;
- a source write, production schedule, external delivery, deployment, or destructive change would be required;
- confidential or personal data cannot be minimized and protected;
- expected totals or tolerances would need to be invented;
- tests expose an unexplained calculation or reconciliation failure;
- rollback or safe rerun behavior cannot be established.

## Output contract

Return these sections:

1. **Implementation status**: `Implemented and tested in the authorized environment`, `Partially implemented`, or `Blocked`. Separate requested, inspected, changed, executed, demonstrated, and unresolved work.
2. **Evidence and assumptions register**: source, classification, location, relevance, limitations, and owner needed for each material item.
3. **Metric implementation register**: metric ID, approved formula reference, grain, dimensions, time and unit rules, implementation location, test coverage, status, and unresolved issue.
4. **Source-to-report traceability**: source fields, extraction, transformations, calculations, report fields, filters, and evidence references.
5. **Repository change manifest**: every file or configuration item changed, purpose, acceptance criterion, applied or proposed state, and rollback method.
6. **Calculation and transformation record**: implemented logic, boundary handling, unresolved conflicts, and direct evidence.
7. **Reconciliation matrix**: metric, period, authoritative supplied value, implemented result, difference, declared tolerance, status, and evidence. Do not fill unavailable values.
8. **Failure and rerun test matrix**: case, fixture, expected observation, actual observation, command, status, idempotency result, recovery result, and evidence.
9. **Disabled schedule and destination evidence**: configured schedule and destination references, disabled state, test sink if any, and evidence without secrets.
10. **Recovery instructions**: detection, containment, safe rerun, reconciliation, output rollback, escalation threshold, and owner.
11. **Data-owner and release-owner handoff**: outstanding definition decisions, access or privacy review, activation prerequisites, release checks, and approvals. Do not make management decisions.
12. **Completion statement**: map every acceptance criterion to implementation and execution evidence. End with the smallest safe next action and its accountable owner.

Completion requires actual authorized repository or configuration changes, traceability for every implemented metric, domain-specific tests with recorded results, reconciliation or an explicit unresolved result, proof that scheduling and delivery remain disabled, and workable recovery instructions. Otherwise report partial or blocked status without claiming the automation is complete, accurate, production-ready, scheduled, or delivered.