Composite Score Aggregation Prompt Template

This prompt is for engineering leads and AI platform teams who need to combine multiple evaluation signals—such as correctness, safety, relevance, and schema conformance—into a single, defensible release gate. The job-to-be-done is not just arithmetic; it is to produce a weighted aggregation formula, normalization rules, and explicit veto conditions that the team can inspect, tune, and audit before shipping a prompt or model change. The ideal user is someone who already has per-axis eval scores (from rubric judges, hallucination detectors, or schema validators) and now needs to decide how those scores combine into a final pass/fail decision.

Use this prompt when you have at least three independent eval axes, when different axes carry different business risk (e.g., safety failures are worse than style issues), and when you need the aggregation logic to be transparent enough for a release governance review. The prompt expects structured inputs: axis names, raw scores, score ranges, and risk priorities. It produces a concrete aggregation spec with weights, normalization functions, and veto conditions. Do not use this prompt when you have only one or two eval signals—a simple AND/OR gate in application code is cheaper and more auditable. Do not use it when the eval axes are not yet calibrated or when individual axis scores are unreliable; aggregation cannot fix broken upstream measurement.

The prompt also includes sensitivity analysis instructions, which is critical for release governance. It asks the model to show how small weight changes alter pass/fail outcomes for borderline cases, helping the team understand which decisions are robust and which are fragile. This is not a prompt for generating a single magic number. It is a prompt for producing a decision framework that can be reviewed, challenged, and version-controlled alongside the eval harness itself. After using this prompt, the output should be converted into executable validation code, not left as a model-generated suggestion. Human review is required before the aggregation formula gates any production release.

This template is the core engine for your composite score aggregation workflow. It accepts a set of individual evaluation scores, their associated metadata (weights, directions, thresholds), and a defined aggregation strategy. The model's job is not to re-evaluate the underlying content but to apply the specified mathematical and logical rules to produce a final, auditable composite score and a structured pass/fail recommendation. Use this when you have already run separate evals (e.g., correctness, relevance, safety) and need a consistent, programmable gate to combine them.

Below is the copy-ready prompt template. All placeholders are in square brackets and must be replaced by your application logic before sending the request to the model. The prompt is designed to be deterministic; it instructs the model to act as a calculator, not a judge. The [AGGREGATION_RULES] placeholder is where you inject your specific formula, such as a weighted sum, a harmonic mean, or a cascading veto logic. The [NORMALIZATION_RULES] section should specify how to scale disparate scores (e.g., 1-5 rubrics vs. 0-1 probabilities) to a common range before aggregation.

textCopy
SYSTEM:
You are a precise score aggregation engine. Your only task is to combine multiple input scores into a single composite score based on the provided rules. Do not re-score, interpret, or critique the inputs. Apply the rules exactly and output the result in the specified JSON schema. If any veto condition is met, the composite score must be set to the veto value and the pass/fail status must be 'FAIL'.

USER:
Aggregate the following evaluation scores into a single composite score.

## INPUT SCORES
[INPUT_SCORES]

## AGGREGATION RULES
[AGGREGATION_RULES]

## NORMALIZATION RULES
[NORMALIZATION_RULES]

## VETO CONDITIONS
[VETO_CONDITIONS]

## OUTPUT SCHEMA
[OUTPUT_SCHEMA]

## CONSTRAINTS
- Apply normalization before aggregation.
- Check veto conditions after calculating the initial composite score.
- Round the final composite score to [DECIMAL_PRECISION] decimal places.
- Set the `pass` field to `true` only if the final composite score is >= [PASS_THRESHOLD] and no veto condition is active.

To adapt this template, start by defining your [INPUT_SCORES] as a structured list of objects, each with a name, value, and weight. The [AGGREGATION_RULES] should be a clear formula, such as weighted_sum = (score1 * weight1) + (score2 * weight2). The [VETO_CONDITIONS] are critical for safety and quality; a typical rule is IF safety_score < 0.5 THEN composite_score = 0 AND pass = false. The [OUTPUT_SCHEMA] should be a strict JSON schema that includes fields for the final composite score, a pass/fail boolean, a list of triggered vetoes, and the normalized inputs used in the calculation. This ensures the output is machine-readable and auditable. For high-stakes release gates, always log the full input and output payload from this prompt to create an audit trail that explains exactly why a build was promoted or blocked.

This prompt is designed to be the final decision layer in an automated evaluation pipeline, not a standalone tool. It consumes structured eval results from upstream judges—such as rubric scores, pairwise comparisons, and hallucination checks—and produces a deterministic aggregation formula, normalization rules, and veto conditions. The output is a machine-readable specification that your release gate logic can execute without further model inference. Treat this prompt as a policy compiler: it translates human-defined quality priorities into executable pass/fail logic.

To integrate this into an application, first ensure that all upstream eval metrics are collected in a consistent schema before calling this prompt. The input should be a JSON object containing metric names, raw scores, score ranges, and any per-metric pass/fail thresholds already defined. The prompt expects a [WEIGHT_PREFERENCES] block where you specify relative importance (e.g., "hallucination_rate" > "latency" > "format_compliance"). After receiving the model's output, validate the generated aggregation formula by running it against a golden dataset of known score combinations where the correct pass/fail outcome is pre-labeled. If the formula produces unexpected results on any golden case, flag it for human review before deployment. Log every aggregation decision with the formula version, input scores, and final verdict for auditability.

For production hardening, implement a sensitivity analysis harness around this prompt. After the model proposes weights, programmatically perturb each weight by ±5% and ±10% and re-evaluate the last 100 release candidates. If the pass/fail outcome flips for more than 2% of cases under minor weight changes, the aggregation is too brittle—reject it and request a revised formula with broader stability margins. Additionally, enforce veto condition validation: any veto rule generated by the prompt (e.g., "fail if hallucination_rate > 0.05") must be cross-checked against your organization's safety and compliance policies before activation. Veto conditions that bypass human-defined red-line thresholds should trigger an immediate escalation. Use a model with strong reasoning capabilities (such as Claude 3.5 Sonnet or GPT-4o) for the aggregation design step, but execute the resulting formula in deterministic application code—never in a model—to ensure consistent, reproducible gate decisions.

Avoid using this prompt for real-time per-request gating. The aggregation formula is designed for batch release gates (daily builds, PR merges, canary promotions), not for scoring individual user interactions. For per-request quality checks, use lightweight, pre-compiled rules derived from a previously approved aggregation run. Store each approved formula as a versioned artifact in your prompt registry alongside its sensitivity analysis report, golden dataset results, and the human approver's identity. When upstream eval metrics change—such as adding a new judge or modifying a rubric—re-run this prompt to generate an updated aggregation formula and repeat the full validation harness before promoting it.