Risk Score Normalization Prompt Across Data Sources

Security data platform teams ingest risk signals from endpoint detection, network analysis, identity providers, and threat intelligence feeds, each with its own scoring scale, direction, and reliability profile. This prompt normalizes heterogeneous risk scores into a single 0-100 scale with documented mapping methodology, source reliability weights, and conflict resolution rules. Use it when you need a unified risk view for downstream escalation decisions, SOC dashboards, or automated response playbooks. The prompt assumes you have already extracted raw scores and metadata from each source and can provide them as structured input. It does not replace your SIEM correlation engine or statistical anomaly detector; it sits between raw signal ingestion and the escalation threshold gate.

The ideal user is a detection engineer, security data platform developer, or automation builder who controls the pipeline feeding data into the model. You must provide a structured array of source objects, each containing the raw score, the source's native scale, the score direction (e.g., higher is riskier), and a reliability weight you have assigned based on historical performance. The prompt is not designed for ad-hoc analyst queries where source data is pasted in manually; it expects programmatic, structured input. If your sources lack documented scales or you cannot assign a reliability weight, do not use this prompt—you will get a mathematically plausible but operationally meaningless normalized score.

Do not use this prompt for real-time blocking decisions without a human review stage. The normalization methodology is deterministic and explainable, but the input weights and mapping rules are policy decisions that carry operational risk. A misconfigured weight can suppress a critical signal or amplify noise. Always validate that the normalized scores preserve the relative risk ordering of your known true-positive and false-positive events before deploying to production. The next step after implementing this prompt is to build an eval harness that compares normalized scores against your historical incident outcomes and flags any inversion where a lower-risk event scores higher than a confirmed threat.

This prompt template is designed for security data platform teams that ingest risk signals from multiple detection systems—such as endpoint detection, network anomaly detectors, and user behavior analytics—each producing scores on different scales with varying reliability. The template normalizes these disparate inputs into a single composite score on a defined output scale, preserving relative risk ordering while documenting the mapping methodology, source weights, and conflict resolution logic. Use this prompt when you need a consistent, auditable normalization layer before downstream escalation or automated decision-making.

textCopy
You are a risk normalization engine for a security data platform. Your task is to ingest risk signals from multiple heterogeneous sources and produce a normalized composite risk score with full explainability.

## INPUT
[INPUT]

## CONTEXT
[CONTEXT]

## OUTPUT_SCHEMA
[OUTPUT_SCHEMA]

## CONSTRAINTS
[CONSTRAINTS]

## EXAMPLES
[EXAMPLES]

## INSTRUCTIONS
1. Parse each input risk signal, extracting the raw score, the source system identifier, the score's native scale (min, max, and whether higher means more or less risky), and any confidence or reliability metadata provided.
2. For each source, map the raw score to a normalized 0–100 scale where 0 represents no risk and 100 represents maximum risk. Document the mapping formula or method used for each source.
3. Apply source reliability weights as defined in [CONTEXT]. If a source's reliability weight is not provided, default to a weight of 1.0 and note this assumption.
4. Compute the composite normalized score as the weighted average of individual normalized scores. If weights are not provided for all sources, use equal weighting and flag this in the output.
5. Detect conflicts between sources. A conflict exists when one source's normalized score exceeds [CONSTRAINTS.conflict_threshold] and another source's normalized score is below [CONSTRAINTS.low_risk_threshold]. For each conflict, apply the resolution rule specified in [CONSTRAINTS.conflict_resolution_rule].
6. If any source score is missing, malformed, or outside its declared native scale, exclude it from the composite calculation and list it in the `excluded_signals` field with a reason.
7. If fewer than [CONSTRAINTS.minimum_sources] valid source scores remain after exclusion, set the composite score to null and set `insufficient_data` to true.
8. Populate the output strictly according to [OUTPUT_SCHEMA]. Do not include fields outside the schema.
9. If [RISK_LEVEL] is "high" or "critical", append a `[HUMAN_REVIEW_REQUIRED]` token at the end of the `normalization_notes` field.

To adapt this template, replace each square-bracket placeholder with concrete values for your environment. [INPUT] should contain the raw risk signals in a structured format—typically a JSON array of objects with fields like source, raw_score, scale_min, scale_max, direction, and confidence. [CONTEXT] should define source reliability weights, such as {"edr": 1.2, "network_anomaly": 0.8, "user_behavior": 0.9}. [OUTPUT_SCHEMA] must be a strict JSON schema definition that downstream systems can validate against. [CONSTRAINTS] should specify operational parameters like conflict_threshold, low_risk_threshold, conflict_resolution_rule (e.g., "prefer_higher_risk" or "flag_for_review"), and minimum_sources. [EXAMPLES] should include at least one normal case and one conflict case with expected outputs. Before deploying, validate that the normalized scores preserve the relative risk ordering of the original signals by running a set of pairwise comparisons through your eval harness.

This prompt is designed to sit inside a data ingestion or risk aggregation pipeline, not as a standalone chat interface. It receives heterogeneous risk signals from multiple detection systems—fraud engines, anomaly detectors, threat intelligence feeds—and produces a normalized composite score with source reliability weights and conflict resolution rules. The implementation harness must treat this prompt as a deterministic transformation step: same inputs should produce structurally identical outputs, and any deviation in schema or score ordering must trigger a validation failure before the normalized score reaches downstream decision systems.

Wire the prompt into an application function that assembles the [INPUT_SOURCES], [SOURCE_RELIABILITY_WEIGHTS], [NORMALIZATION_METHOD], and [CONFLICT_RESOLUTION_RULES] placeholders from your security data platform's configuration store. Each source must include its raw score, score range, timestamp, and a unique source identifier. Before calling the model, validate that all required source fields are present and that score ranges are explicitly declared—missing range metadata is the most common cause of normalization drift. After receiving the model response, run a structured output validator that checks: (1) the normalized score falls within the declared [TARGET_RANGE], (2) every input source appears in the mapping methodology section, (3) relative risk ordering is preserved (a source scoring higher than another must not have its normalized contribution inverted), and (4) conflict resolution notes are present when source scores diverge beyond the [DIVERGENCE_THRESHOLD]. If validation fails, retry once with the validation errors appended to the [CONSTRAINTS] field. If the retry also fails, log the failure, attach the raw sources and partial output, and route to a human review queue rather than silently accepting a malformed score.

For model choice, prefer a model with strong JSON schema adherence and low temperature (0–0.1). This is a structured transformation task, not a creative reasoning task, so higher temperatures introduce unnecessary variance in weight assignments and conflict explanations. Implement request-level logging that captures the prompt version, source identifiers, raw scores, normalized output, validation results, and any retry attempts. This audit trail is essential for downstream governance and for debugging normalization failures when risk analysts question why a particular composite score was assigned. Avoid using this prompt for real-time blocking decisions without a human-in-the-loop gate: normalized scores should feed into a threshold evaluation step that escalates rather than auto-blocks until the normalization methodology has been calibrated against historical outcomes in your environment.