# Assure an AI System Change for Production Release

Workflow ID: AMO-W-000021
Workflow URL: https://amo.ng/workflows/ai-system-change-production-release-assurance

## Outcome

A release decision package containing configuration lineage, change-control evidence, calibrated thresholds, adversarial coverage, production-feedback coverage, metric-integrity findings, owners, rollback conditions, and an Approve, Approve with conditions, Hold, or Reject recommendation.

## Before you begin

- Exact proposed AI system change, approved baseline, deployed prompt and configuration inventory, and accountable owners
- Change request, dependencies, evaluation evidence, acceptance criteria, affected workflows, users, data, tools, and providers
- Regression results by slice, measurement uncertainty, historical variance, and incident or production-feedback evidence
- Threat model, adversarial cases, safety and security controls, monitoring, deployment, rollback, and recovery plans
- Current evaluation metrics, target outcomes, incentives, known proxies, and release authority

## Step 1 — Reconcile the approved and deployed baseline

**Prompt**

Production Prompt and Configuration Drift Audit

**Instructions**

Compare approved prompts, policies, model and tool settings, routing, retrieval, safety configuration, and runtime variants with what is actually deployed. Trace authorized, unauthorized, stale, and unexplained drift.

**Input for this step**

Provide approved artifacts, deployment manifests and exports, version or change history, environment inventories, runtime traces, owner records, and known exceptions.

**Carry forward**

Carry the configuration lineage, drift register, affected environments, evidence gaps, and adopt, rollback, or revalidate dispositions into change-control review.

**Review note**

The system owner and release owner confirm the deployed baseline and authorize any rollback or adoption of previously unapproved drift.

**Prompt ID**

AMO-P-000300

**Prompt URL**

https://amo.ng/prompts/production-prompt-configuration-drift-audit

**Prompt content**

Audit whether an AI system is running the exact prompt and configuration state that its owners approved. Include system and developer prompts, templates, policies, model and version, retrieval settings, tool definitions, decoding controls, feature flags, and environment-specific overrides.

Provide:
- Approved versions, hashes, manifests, release records, and intended environment matrix: [Approved prompt and configuration baseline]
- Deployed artifacts, resolved configuration, environment values, gateway settings, and runtime version identifiers: [Deployed artifacts and environment inventory]
- Pull requests, tickets, approvals, emergency changes, deployment records, and rollback history: [Change deployment and approval records]
- Timestamped traces, rendered prompts, model routes, tool schemas, retrieval settings, outputs, and incidents: [Runtime traces and behavior evidence]
- Evaluation results, regression thresholds, release claims, and accepted limitations: [Evaluation results and acceptance criteria]
- Recovery options, production constraints, and prompt, service, security, and release owners: [Rollback constraints and owners]

Do not reconstruct a secret or omitted prompt from behavior alone. Do not claim an environment or provider was inspected unless its artifacts are supplied. Treat version labels without content hashes or resolved configuration evidence as weak identifiers. Separate deployed drift from expected environment variation and from behavior drift with no proven configuration change.

Audit procedure:

1. Establish the approved baseline.
   Create a component inventory with exact identifiers, content hashes where supplied, owning role, approved environment, dependency versions, and acceptance evidence. Flag mutable aliases, undocumented defaults, and missing baselines.

2. Resolve the effective production state.
   Map the artifacts and configuration actually used for representative runtime records. Include template rendering, injected policies, gateway transformations, model routing, tool schemas, retrieval settings, feature flags, and post-processing.

3. Compare baseline to effective state.
   Classify differences as Approved release, Expected environment variance, Emergency authorized change, Unauthorized drift, Stale deployment, Partial rollout, Mutable dependency change, or Not assessable.

4. Reconstruct material drift.
   For each material difference, identify first evidence, likely change path, affected environments and traffic, duration, accountable owner, observed behavior, and whether the drift invalidates prior evaluation evidence.

5. Assess decision impact.
   Determine whether the drift changes safety boundaries, tool authority, data handling, answer contract, retrieval behavior, quality claims, cost or latency assumptions, or regulatory/contractual commitments. Do not infer causation from temporal correlation without supporting evidence.

6. Select a disposition per drift item.
   Choose Roll back to approved baseline, Adopt through change control, Restrict affected traffic, Revalidate before decision, or Monitor as accepted variance. State smallest safe action, owner, approval, dependencies, and rollback trigger.

7. Design recurrence controls.
   Define immutable artifact identifiers, resolved-config capture, deployment attestation, runtime sampling, hash comparison, alert thresholds, emergency-change expiry, and evaluation invalidation rules proportionate to the risk.

If an approved baseline, component hash, deployment record, or owner decision is missing or conflicts with another source, request the blocking evidence and keep the affected drift status Unknown. Do not infer the approved configuration from the currently running state, and do not close the audit while a material baseline conflict remains unresolved.

Required deliverable:

# Production Prompt and Configuration Drift Audit

## Approved Baseline Inventory
| Component | Approved identifier/hash | Environment | Owner | Approval evidence | Evaluation evidence |
|---|---|---|---|---|---|

## Effective Production Inventory
| Component | Observed identifier/config | Evidence source | Traffic/window | Confidence | Missing proof |
|---|---|---|---|---|---|

## Drift Register
| Difference | Classification | First evidence | Scope | Behavior/claim impact | Prior evaluation still valid? | Owner |
|---|---|---|---|---|---|---|

## Disposition Plan
| Priority | Drift item | Decision | Smallest safe action | Approval | Verification | Rollback trigger |
|---|---|---|---|---|---|---|

## Recurrence Controls
| Control | Drift detected | Evidence retained | Threshold | Owner | Cadence |
|---|---|---|---|---|---|

## Audit Conclusion
- Production state matches approval: Yes / Partially / No / Not assessable
- Release claims invalidated or narrowed:
- Immediate restrictions:
- Unresolved evidence:
- Next owner decision:

Complete the audit only when every material production component is reconciled to an approved state or a named disposition, and the release owner can tell which evaluation claims remain valid.


## Step 2 — Gate change-control readiness

**Prompt**

AI System Change-Control Readiness Brief

**Instructions**

Assess the exact change across impact, dependencies, evaluation scope, approvals, deployment sequencing, monitoring, rollback, recovery, and evidence quality.

**Input for this step**

Use the reconciled baseline with the change request, architecture and dependency evidence, affected users and data, evaluation plan, approvals, deployment plan, monitoring, rollback, and recovery evidence.

**Carry forward**

Carry the readiness disposition, blockers, required approvals, affected boundaries, evidence gaps, and release conditions into threshold calibration.

**Review note**

System, data, security, privacy, and release owners decide the requirements within their authority; a readiness brief does not authorize release.

**Prompt ID**

AMO-P-000303

**Prompt URL**

https://amo.ng/prompts/ai-system-change-control-readiness-brief

**Prompt content**

Prepare a change-control readiness brief for a proposed modification to an operating AI system. Evaluate the combined effect of changes to models, prompts, policies, retrieval, data, tools, routing, orchestration, validators, and downstream integrations.

Inputs:
- Change scope, rationale, intended outcome, artifacts, versions, and requested release window: [Proposed change and intended outcome]
- Current approved architecture, behavior, versions, dependencies, environments, and service commitments: [Current system and dependency baseline]
- Threat, privacy, safety, operational, user, contractual, and compliance impact evidence: [Impact and risk evidence]
- Test cases, datasets, slice results, regression comparisons, failure evidence, and accepted thresholds: [Evaluation and test evidence]
- Rollout stages, observability, alerting, stop conditions, rollback method, recovery time, and communications: [Deployment monitoring and rollback plan]
- Change policy, emergency constraints, separation of duties, maintenance limits, and accountable owners: [Approvals constraints and owners]

Use supplied evidence only. Do not claim that tests passed, a dependency is compatible, rollback works, or approvals exist unless supported. Distinguish proposed changes from implemented changes and offline evidence from production evidence. Treat coupled changes as a combined release risk rather than evaluating each artifact in isolation.

Review:

1. Establish the exact change set.
   Inventory changed and unchanged components, versions, owners, environments, migrations, feature flags, data transformations, tool permissions, and user-facing behavior. Identify mutable or unresolved dependencies.

2. Map impact propagation.
   Trace how the change could affect input handling, context, retrieval, output, tool use, data exposure, safety policy, latency, cost, logging, user experience, and downstream decisions. Separate confirmed dependencies from inferred ones.

3. Define claims and acceptance evidence.
   List what the release is expected to improve or preserve. Map each claim to representative evaluation slices, negative tests, operational tests, and explicit thresholds. Identify claims unsupported by the supplied evidence.

4. Review risk and authority boundaries.
   Examine data classification, access changes, new actions, irreversible effects, policy exceptions, vendor changes, regional constraints, and roles authorized to approve the change. Flag changes requiring security, privacy, legal, data, or product review.

5. Assess deployment safety.
   Review sequencing, compatibility, canary population, traffic ramp, observability, alert thresholds, rollback trigger, rollback artifact, data reversibility, queued work, external effects, and incident ownership. A rollback plan without a tested restoration path is incomplete.

6. Review compound and change-volume risk.
   Identify simultaneous changes that make attribution difficult, invalidate prior tests, or exceed a safe observability window. Recommend separating changes only when it materially improves diagnosis or reversibility.

7. Make a readiness decision.
   Choose Ready for controlled release, Ready after named conditions, Split and re-evaluate, Hold for evidence, or Reject current change. State allowed scope, owner approvals, release window, monitoring gates, and rollback authority.

Required deliverable:

# AI System Change-Control Readiness Brief

## Change Set and Intended Claims
| Component | Current state | Proposed state | Owner | Intended claim | Evidence status |
|---|---|---|---|---|---|

## Impact and Dependency Map
| Change | Dependency/path | Potential effect | Evidence | Risk | Review owner |
|---|---|---|---|---|---|

## Evaluation and Control Evidence
| Claim or invariant | Test/slice | Threshold | Result supplied | Gap | Release consequence |
|---|---|---|---|---|---|

## Deployment and Rollback Gate
| Gate | Required evidence | Owner | Stop condition | Rollback action | Status |
|---|---|---|---|---|---|

## Readiness Decision
- Decision:
- Allowed release scope:
- Conditions before release:
- Required approvals:
- Monitoring and ramp limits:
- Rollback authority and trigger:
- Unsupported claims:
- Residual uncertainty:

Completion requires an exact change inventory, traceable acceptance evidence, a reversible or explicitly accepted deployment path, and accountable approval for every consequential boundary crossed.


## Step 3 — Calibrate regression acceptance thresholds

**Prompt**

Regression Acceptance Threshold Calibration

**Instructions**

Set risk-based thresholds using baseline variance, measurement error, critical slices, practical significance, asymmetric harm, and explicit release trade-offs.

**Input for this step**

Provide the change boundary, baseline and candidate results, sample sizes, uncertainty, slice exposure, historical variance, guardrails, and release risk tolerance.

**Carry forward**

Carry the threshold register, non-compensable gates, uncertainty, exceptions, and revalidation triggers into adversarial coverage review.

**Review note**

The evaluation and domain owners approve measurement interpretation; the release owner approves threshold use for this change.

**Prompt ID**

AMO-P-000304

**Prompt URL**

https://amo.ng/prompts/regression-acceptance-threshold-calibration

**Prompt content**

Calibrate acceptance thresholds for an AI regression comparison before the threshold is used to approve a model, prompt, retrieval, routing, policy, or workflow change.

Provide:
- Exact release decision, protected behaviors, unacceptable failures, and risk tier: [Release decision and risk boundary]
- Metrics, rubrics, denominators, slices, aggregation, directionality, and scorer definitions: [Metrics slices and scoring rules]
- Current production or approved-baseline results, repeat runs, sampling uncertainty, scorer variance, and historical drift: [Baseline results and variance evidence]
- Candidate results if available, or the planned comparison design and sample allocation: [Candidate evidence or planned comparison]
- User, safety, compliance, operational, latency, and financial consequences of false acceptance and false rejection: [Operational impact and error costs]
- Sample, time, compute, policy, and deployment constraints plus evaluation and release owners: [Constraints owners and review cadence]

Do not choose thresholds merely because they match a convenient round number or a single historical score. Do not invent variance, confidence intervals, effect sizes, sample sizes, or error costs. Separate statistical detectability from practical acceptability. A strong aggregate result must not compensate for a material safety or protected-slice regression unless policy explicitly permits that trade.

Calibration method:

1. Define the decision contract.
   State what the threshold authorizes, the baseline being protected, acceptable degradation if any, non-compensable failures, and who owns the release decision.

2. Audit metric fitness.
   Check construct alignment, scoring reliability, denominator stability, missingness, boundedness, class imbalance, aggregation effects, and susceptibility to gaming. Mark metrics that cannot support a release threshold.

3. Characterize the baseline.
   Summarize supplied central tendency, dispersion, run-to-run variance, scorer disagreement, slice sample size, and temporal stability. Identify baselines too weak or unstable for calibration.

4. Price decision errors.
   Describe the consequence of accepting a harmful regression and rejecting a useful improvement. Use qualitative bands when credible monetary or impact estimates are unavailable.

5. Propose threshold types.
   Compare absolute floor, relative degradation budget, non-inferiority margin, confidence-bound rule, paired-case win/loss rule, zero-tolerance event rule, and operational stop rule. Use different rules for different metrics or slices when justified.

6. Check feasibility and power.
   Determine whether planned sample and repeated runs can distinguish the proposed margin from noise using supplied evidence. If not, recommend more evidence, a wider but risk-acceptable margin, a paired design, or a hold—not false precision.

7. Resolve aggregation and slice gates.
   Specify which gates are global, per slice, non-compensable, or monitored during canary. Address multiple comparisons and rare critical failures proportionately.

8. Produce a calibration decision.
   Recommend thresholds, rationale, evidence limits, re-estimation triggers, and an owner-approved exception path. Label provisional thresholds clearly.

The evaluation owner defines the evidence set, while the release owner approves any threshold used as a production gate; this analysis does not authorize release. For every proposed threshold, provide acceptance evidence with the expected observation, actual observation when available, sampling uncertainty, and reconciliation of false-accept and false-reject consequences. Do not claim calibration was executed unless the underlying results are supplied.

Record approval from the evaluation owner for the evidence set and approval from the release owner before the threshold becomes a production gate.

Required deliverable:

# Regression Acceptance Threshold Calibration

## Decision and Risk Contract
- Change being gated:
- Baseline protected:
- Non-compensable failures:
- False-acceptance consequence:
- False-rejection consequence:

## Metric Fitness Review
| Metric/slice | Intended construct | Reliability evidence | Noise/drift | Gaming risk | Fit for gate? |
|---|---|---|---|---|---|

## Baseline Variability Record
| Metric/slice | Baseline | Sample/repeats | Variance evidence | Stability | Limitation |
|---|---|---|---|---|---|

## Calibrated Gates
| Metric/slice | Gate type | Threshold/margin | Rationale | Sample rule | Compensable? | Owner |
|---|---|---|---|---|---|---|

## Release Interpretation
| Outcome | Decision | Canary/monitoring condition | Exception authority |
|---|---|---|---|

## Recalibration Triggers
List changes in traffic, rubric, judge, prevalence, model, prompt, retrieval, policy, or impact that invalidate the thresholds.

Completion requires a threshold for every material protected behavior, explicit treatment of uncertainty and slices, and a release interpretation that cannot hide a critical regression behind an aggregate score.


## Step 4 — Review adversarial evaluation coverage

**Prompt**

Adversarial Evaluation Coverage Review

**Instructions**

Map credible abuse and failure hypotheses to the changed surfaces, adversarial cases, production controls, detection signals, and release-blocking gaps.

**Input for this step**

Supply the change and threat boundaries, system interfaces, tools and data access, historical failures, test inventory and results, mitigations, and calibrated gates.

**Carry forward**

Carry the adversarial coverage map, exposed surfaces, unsupported mitigations, blockers, and required tests into production-feedback reconciliation.

**Review note**

Security, safety, domain, and release owners decide which uncovered scenarios block release or require bounded restrictions.

**Prompt ID**

AMO-P-000305

**Prompt URL**

https://amo.ng/prompts/adversarial-evaluation-coverage-review

**Prompt content**

Review whether adversarial evaluation evidence covers the credible abuse cases and failure modes of an AI system's actual production boundary. Focus on threat-to-test traceability, not the volume or novelty of prompts.

Evidence:
- Intended users, capabilities, actions, data, deployment context, and release claims: [System scope and release claims]
- Threat actors, assets, trust boundaries, misuse cases, failure hypotheses, and severity rationale: [Threat model and abuse hypotheses]
- Test cases, mutations, datasets, harness settings, results, failures, and reviewer notes: [Evaluation cases and execution records]
- Models, prompts, retrieval, memory, tools, identities, interfaces, filters, monitoring, and containment: [Architecture surfaces and controls]
- Incidents, near misses, abuse reports, support feedback, red-team findings, and observed attack variants: [Production incidents and feedback]
- Accepted risk, release threshold, policy constraints, security owner, evaluation owner, and release owner: [Risk tolerance and accountable owners]

Do not treat a test title as proof of coverage. Do not invent an attack result or claim that a control was bypassed unless execution evidence is supplied. Separate test design coverage from executed coverage, successful defense, failure detection, and containment. Avoid producing novel exploit instructions beyond what is necessary to describe a bounded test objective.

Coverage review:

1. Bound the evaluated system.
   Identify protected assets, allowed behavior, consequential actions, interfaces, user roles, data classes, and release claims. Flag architecture surfaces omitted from the supplied threat model.

2. Normalize threat hypotheses.
   Express each credible threat as actor/precondition, attack or failure path, target asset or invariant, expected harm, and observable success/failure condition. Consolidate duplicates without losing materially different preconditions.

3. Build a threat-to-test matrix.
   Map each hypothesis to test cases, variants, environments, system surfaces, evaluator/oracle, and execution evidence. Distinguish Direct, Partial, Proxy-only, Design-only, and Missing coverage.

4. Assess test strength.
   Review realism, adaptiveness, multi-turn behavior, encoded/indirect inputs, tool and retrieval paths, identity contexts, state persistence, rate effects, chained failures, and negative controls where relevant. Identify tests that exercise only a mock or obsolete configuration.

5. Evaluate oracle and control evidence.
   Determine whether the test can tell prevention, safe refusal, detection, containment, and recovery apart. Flag weak graders, ambiguous expected behavior, silent side effects, and controls whose operation is not observable.

6. Incorporate production learning.
   Map supplied incidents and feedback to existing hypotheses and tests. Identify recurring production failures absent from the evaluation or sanitized regression bank.

7. Prioritize gaps.
   Rank gaps by credible exposure, severity, control weakness, test feasibility, and release claim—not by arbitrary numeric scoring. Name the minimum test or evidence needed to close each gap.

8. Make a release-coverage decision.
   Choose Adequate for stated scope, Adequate with restrictions, Conditional on named tests, or Inadequate. State excluded claims and untested surfaces.

Keep testing within the authorized evaluation environment and supplied data boundary; do not probe production systems or real users. The security reviewer approves threat coverage and the release owner approves residual-risk acceptance. For each material threat, require acceptance evidence showing the expected observation, actual observation when tested, coverage status, and unresolved gap. Proposed adversarial tests are not executed results.

Required deliverable:

# Adversarial Evaluation Coverage Review

## System and Threat Boundary
| Asset/invariant | Surface | Actor/precondition | Consequence | Evidence source |
|---|---|---|---|---|

## Threat-to-Test Traceability Matrix
| Threat hypothesis | Test IDs | Variants/surfaces | Oracle | Execution evidence | Coverage status | Gap |
|---|---|---|---|---|---|---|

## Test-Strength Findings
| Test/group | Realism limitation | Obsolete/missing surface | Oracle weakness | Decision impact |
|---|---|---|---|---|

## Production Feedback Coverage
| Incident/feedback pattern | Existing test | Representation quality | Regression case needed | Owner |
|---|---|---|---|---|

## Priority Coverage Backlog
| Priority | Missing coverage | Minimum safe test | Required evidence | Owner | Release consequence |
|---|---|---|---|---|---|

## Coverage Decision
- Decision:
- Release scope supported:
- Restricted or unsupported scope:
- Tests required before release:
- Residual threat uncertainty:

Completion requires traceability for every material threat hypothesis, explicit separation of designed and executed coverage, and a release scope no broader than the tested system surfaces and oracles support.


## Step 5 — Reconcile production feedback to evaluation coverage

**Prompt**

Production Feedback-to-Evaluation Gap Analysis

**Instructions**

Trace incidents, reviewer corrections, user feedback, escalations, and operational failures into the evaluation suite. Identify absent, stale, weakly weighted, or non-representative regression evidence.

**Input for this step**

Provide production feedback and incident records, reviewer corrections, evaluation cases and weights, sampling and triage rules, version history, and prior-step findings.

**Carry forward**

Carry the feedback lineage, missing or stale cases, weighting defects, dataset actions, and residual blind spots into metric-integrity review.

**Review note**

The evaluation, product, service, and data owners approve feedback inclusion, privacy treatment, prioritization, and revalidation work.

**Prompt ID**

AMO-P-000306

**Prompt URL**

https://amo.ng/prompts/production-feedback-evaluation-gap-analysis

**Prompt content**

Analyze whether material production feedback is represented accurately in the evaluations used to approve and monitor an AI system. Convert observed failures and corrections into a prioritized, privacy-safe evaluation maintenance decision.

Provide:
- Current system, release claims, user populations, task slices, and decisions supported by evaluation: [System release and evaluation scope]
- Sanitized incidents, complaints, reviewer corrections, escalations, overrides, support tickets, outcome signals, and trace summaries: [Production feedback and incident evidence]
- Evaluation datasets, test cases, rubrics, graders, slices, thresholds, run history, and known exclusions: [Current evaluation assets and results]
- Feedback sampling, severity, taxonomy, deduplication, triage, and follow-up methods: [Sampling taxonomy and triage rules]
- Consent, privacy, retention, rights, security, review capacity, and evaluation/release owners: [Privacy constraints and accountable owners]

Do not equate feedback frequency with prevalence unless collection supports that inference. Do not copy sensitive production content into tests without authorization and sanitization. Distinguish user preference, product defect, model failure, retrieval failure, policy issue, workflow issue, and measurement artifact. Do not claim that an evaluation would reproduce a failure unless execution evidence exists.

Analysis:

1. Bound the feedback population.
   Describe collection channels, period, exposed traffic, sampling biases, missing populations, deduplication, and severity rules. Identify feedback that cannot support prevalence estimates.

2. Normalize production signals.
   Group evidence into stable failure or correction patterns while preserving important context such as task, user, language, model, prompt, tool, retrieval, policy, and downstream consequence. Keep ambiguous cases unresolved.

3. Map signals to evaluation assets.
   For each material pattern, find the closest test case, slice, rubric criterion, grader behavior, and threshold. Classify representation as Direct and current, Partial, Proxy, Stale, Misweighted, Mislabelled, or Missing.

4. Diagnose the gap mechanism.
   Determine whether the gap comes from feedback capture, triage, privacy constraints, taxonomy, sampling, dataset curation, rubric design, grader behavior, test execution, thresholding, or release decision use.

5. Assess decision impact.
   Explain which release or monitoring claims become weaker because of each gap. Identify failures that were present in evaluation but hidden by aggregation or accepted thresholds.

6. Design safe evaluation updates.
   Specify the smallest representative case, slice, rubric change, grader calibration sample, threshold change, or monitoring link needed. Include provenance, sanitization, consent/rights, label ownership, and expiry or refresh rules.

7. Prioritize and assign.
   Rank by harm, recurrence evidence, claim impact, coverage absence, and feasible remediation. Do not manufacture a numeric priority score when inputs do not support one.

8. Define closure.
   Require a trace from production evidence to approved sanitized case, executable result, release interpretation, and recurrence monitoring.

The privacy or data owner must approve use of production-derived feedback, the evaluation owner approves benchmark changes, and the release owner retains authority over deployment gates. Do not copy sensitive records outside the authorized evidence boundary or treat this analysis as approval to change production evaluation policy.

Required deliverable:

# Production Feedback-to-Evaluation Gap Analysis

## Feedback Population and Limitations
- Period and traffic represented:
- Channels:
- Sampling/deduplication method:
- Biases and missing populations:

## Production Signal Taxonomy
| Pattern | Evidence count/status | Context/slice | Consequence | Confidence | Prevalence claim allowed? |
|---|---|---|---|---|---|

## Feedback-to-Evaluation Map
| Production pattern | Existing asset | Representation | Gap mechanism | Release/monitoring impact | Owner |
|---|---|---|---|---|---|

## Evaluation Maintenance Backlog
| Priority | Update | Source evidence | Sanitization/rights check | Acceptance test | Decision affected | Owner |
|---|---|---|---|---|---|---|

## Decision Summary
- Evaluation claims still supported:
- Claims narrowed or suspended:
- Updates required before next release:
- Signals retained for monitoring only:
- Unresolved uncertainty:

Completion requires every high-severity production pattern to be mapped or explicitly excluded with rationale, and every new evaluation asset to retain safe provenance back to the production learning it represents.


## Step 6 — Test metric integrity and issue the release recommendation

**Prompt**

Evaluation Metric Gaming and Proxy Failure Audit

**Instructions**

Determine whether optimization against current evaluation metrics rewards undesirable behavior, hides target failure, or distorts release decisions. Reconcile this finding with every prior gate.

**Input for this step**

Provide target outcomes, current metrics and scorecards, optimization incentives, countermetrics, observed behavior, threshold and coverage findings, and the accountable release criteria.

**Carry forward**

Produce the final configuration, change-control, threshold, coverage, proxy-risk, monitoring, rollback, and release decision record.

**Review note**

The release owner issues the final decision after evaluation, domain, security, safety, product, and service owners have recorded their dispositions.

**Prompt ID**

AMO-P-000307

**Prompt URL**

https://amo.ng/prompts/evaluation-metric-gaming-proxy-failure-audit

**Prompt content**

Audit whether an AI evaluation metric is being used as a trustworthy measure of the target outcome or has become a gameable proxy that rewards the wrong behavior.

Evidence:
- Real-world outcome, protected invariants, users, harms, and decision the metric informs: [Target outcome and decision context]
- Metric definitions, labels, rubrics, graders, transformations, weights, aggregation, thresholds, and dashboards: [Metrics rubrics and aggregation rules]
- Training, tuning, selection, prompting, vendor, team, and release incentives tied to the metric: [System incentives and optimization process]
- Historical runs, production outcomes, slice results, reviewer evidence, downstream measures, and confidence information: [Evaluation production and outcome evidence]
- Incidents, edge cases, suspicious improvements, regressions, complaints, and populations where the proxy may fail: [Known failure cases and affected slices]
- Accepted error, non-compensable harms, evaluation owner, product owner, risk reviewer, and release owner: [Risk tolerance and accountable owners]

Do not infer gaming solely from a score improvement. Do not assume correlation proves the proxy causes or predicts the target outcome. Do not invent raw data, incentives, or counterfactual results. Separate deliberate gaming, optimization pressure, specification error, measurement error, distribution shift, label leakage, and aggregation artifacts.

Audit:

1. Define the target-proxy contract.
   State the real outcome or invariant, why the metric is expected to represent it, the decision it authorizes, and conditions under which that relationship may fail.

2. Trace the metric construction.
   Review data source, sampling, labels, rubric, judge, transformations, weights, exclusions, missing data, threshold, and aggregation. Identify degrees of freedom available to the optimized system or team.

3. Map incentives and attack surfaces.
   Identify who or what adapts to the metric, information exposed during optimization, repeated test use, feedback leakage, and ways to improve the score without improving the target. Keep hypothetical paths separate from observed behavior.

4. Test proxy validity from supplied evidence.
   Compare metric movement with direct outcome evidence, independent reviewer evidence, protected-slice results, incidents, and downstream measures. Look for divergence, saturation, nonlinearity, reversal, and improvements caused by case exclusion or aggregation.

5. Find compensating and hidden failures.
   Determine whether gains in common cases mask severe losses in rare slices; whether averages hide abstention, refusal, verbosity, cost, latency, or safety failures; and whether one metric rewards behavior another penalizes.

6. Classify findings.
   Use Valid within tested range, Weak proxy, Broken proxy, Gameable but controlled, Actively distorted, or Not assessable. State evidence and decision consequence for each metric/slice.

7. Design a safer measurement contract.
   Recommend direct measures, counter-metrics, holdouts, blind review, refreshed cases, protected-slice gates, independent outcome sampling, or reduced decision authority. Prefer the smallest change that restores decision integrity.

8. Make a use decision.
   Choose Retain, Retain with counter-metrics, Restrict to named scope, Recalibrate, Replace, or Suspend. Name the owner and evidence required before broader use.

Required deliverable:

# Evaluation Metric Gaming and Proxy Failure Audit

## Target-Proxy Contract
| Target outcome/invariant | Proxy metric | Decision use | Assumed relationship | Known limit |
|---|---|---|---|---|

## Construction and Incentive Map
| Metric component | Evidence/source | Optimization exposure | Manipulation or distortion path | Observed/hypothetical |
|---|---|---|---|---|

## Proxy Validity Findings
| Metric/slice | Direct outcome evidence | Proxy movement | Divergence | Classification | Decision impact |
|---|---|---|---|---|---|

## Hidden Trade-offs
| Apparent gain | Compensating loss | Slice/condition | Evidence | Non-compensable? |
|---|---|---|---|---|

## Measurement Repair
| Priority | Change | Failure addressed | Acceptance evidence | Owner |
|---|---|---|---|---|

## Metric Use Decision
- Decision:
- Authorized scope:
- Required counter-metrics or gates:
- Unsupported claims:
- Reassessment trigger:

Completion requires a documented target-proxy relationship, evidence on material divergence and incentives, and a decision boundary that prevents an aggregate score from authorizing outcomes it does not measure.


## Completion criteria

The workflow is complete when:

- Approved and deployed prompt, model, policy, tool, and runtime configuration are reconciled for the exact change.
- Change ownership, dependencies, approvals, deployment, monitoring, rollback, and recovery evidence have explicit dispositions.
- Regression thresholds account for uncertainty, practical significance, critical slices, and non-compensable failures.
- Credible adversarial hypotheses and production feedback have traceable evaluation coverage or explicit blockers.
- Metric gaming and proxy risks are bounded, and the release owner has an Approve, Approve with conditions, Hold, or Reject recommendation with observable conditions.