Dynamic Threshold Adjustment Prompt Based on Trends

This prompt is designed for risk operations, security engineering, and fraud operations teams who need to adapt static detection thresholds to evolving patterns in their data. Use it when alert volumes are drifting, seasonal patterns are shifting, or new attack vectors are changing the signal-to-noise ratio of your detection systems. The prompt ingests historical alert data, current threshold configurations, and known environmental context (such as product launches, marketing campaigns, or known threat campaigns) and produces a structured recommendation for threshold adjustments.

It is not a replacement for a statistical forecasting model or a real-time anomaly detection system. It is a decision-support tool that packages trend analysis, impact projections, and rollback criteria into a format that a human reviewer or an automated policy engine can act on. The output is designed to be consumed by a threshold configuration system or reviewed by a risk operations analyst before deployment. Do not use this prompt when you need millisecond-latency decisions, when the cost of a single incorrect threshold change is catastrophic without human review, or when your detection system requires formal regulatory certification for every parameter change.

Before using this prompt, ensure you have at least 30 days of historical alert data, the current threshold values for each rule, and a clear definition of what constitutes a true positive and false positive in your environment. The prompt's effectiveness degrades significantly when historical data is sparse, when ground-truth labels are unreliable, or when the business context (such as a major product launch) is not provided. Always pair the output with a rollback plan and a short monitoring window after deployment.

This prompt template is designed to be integrated into a risk operations workflow where detection thresholds need periodic recalibration. It takes historical trend data, current threshold configurations, and business constraints as input, then produces a structured recommendation for threshold adjustments. The output includes supporting trend analysis, projected impact on alert volume and detection coverage, and explicit rollback criteria. Use this when your team needs data-driven threshold changes that can be reviewed, approved, and audited.

textCopy
You are a risk operations analyst reviewing detection thresholds for [SYSTEM_NAME]. Your task is to recommend threshold adjustments based on recent trend data, seasonal patterns, and known events.

## CURRENT CONFIGURATION
Threshold ID: [THRESHOLD_ID]
Current Value: [CURRENT_THRESHOLD]
Threshold Type: [THRESHOLD_TYPE]
Detection Coverage Target: [COVERAGE_TARGET]%
Maximum Acceptable False Positive Rate: [MAX_FPR]%

## TREND DATA
Time Range: [START_DATE] to [END_DATE]
Granularity: [GRANULARITY]

[TREND_DATA_TABLE]

## KNOWN EVENTS AND SEASONAL PATTERNS
[KNOWN_EVENTS]

## BUSINESS CONSTRAINTS
Alert Volume Capacity: [MAX_ALERTS_PER_PERIOD]
Regulatory Requirements: [REGULATORY_REQUIREMENTS]
Risk Appetite Statement: [RISK_APPETITE]

## OUTPUT REQUIREMENTS
Produce a JSON object with the following structure:
{
  "recommendation": {
    "adjusted_threshold": number,
    "adjustment_direction": "increase" | "decrease" | "maintain",
    "confidence_level": "high" | "medium" | "low",
    "rationale_summary": "string"
  },
  "trend_analysis": {
    "observed_trend": "string",
    "trend_strength": "strong" | "moderate" | "weak",
    "supporting_evidence": ["string"],
    "contradictory_evidence": ["string"],
    "seasonal_pattern_match": "string",
    "known_event_impact": "string"
  },
  "impact_projection": {
    "estimated_alert_volume_change_percent": number,
    "estimated_coverage_change_percent": number,
    "estimated_false_positive_change_percent": number,
    "capacity_risk": "within_capacity" | "near_capacity" | "exceeds_capacity",
    "detection_gap_risk": "none" | "low" | "medium" | "high"
  },
  "rollback_criteria": {
    "trigger_conditions": ["string"],
    "monitoring_period": "string",
    "revert_threshold": number,
    "escalation_contact": "string"
  },
  "validation_notes": {
    "data_quality_issues": ["string"],
    "assumptions_made": ["string"],
    "limitations": ["string"]
  }
}

## CONSTRAINTS
- Do not recommend adjustments that would cause alert volume to exceed [MAX_ALERTS_PER_PERIOD].
- Flag any recommendation that reduces detection coverage below [COVERAGE_TARGET]%.
- If trend data is insufficient for a confident recommendation, set confidence_level to "low" and explain what additional data would be needed.
- Account for [KNOWN_EVENTS] when interpreting trends to avoid overfitting to temporary patterns.
- Include specific, measurable rollback criteria that can be automated.

Adapt this template by replacing each square-bracket placeholder with data from your detection systems, configuration store, and operational context. The [TREND_DATA_TABLE] should contain historical alert volumes, detection rates, and false positive rates at the specified granularity. The [KNOWN_EVENTS] field should include product launches, marketing campaigns, system migrations, holidays, or any events that could create temporary anomalies. Before sending this prompt to the model, validate that all placeholders are resolved and that the trend data covers a sufficient time window to distinguish signal from noise. For high-risk threshold changes affecting regulatory compliance, route the model's output through a human approval step before applying the adjustment.

This prompt is designed for a scheduled cadence (daily or weekly) or an event-driven trigger when a significant shift in alert volume, false-positive rate, or detection coverage is detected by your monitoring systems. It is not a real-time prompt and should not be called per-transaction. The implementation harness should treat this as a batch analysis job: gather the required trend data, assemble the prompt with the [TREND_DATA], [CURRENT_THRESHOLDS], and [BUSINESS_CONSTRAINTS] placeholders, and call a capable reasoning model (such as GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro). The model's output is a structured recommendation, not an executable action, so the harness must parse, validate, and route the output for human approval before any threshold change is applied to production systems.

Wiring the prompt into an application requires a multi-step pipeline. First, a data aggregation step must query your observability platform (e.g., Datadog, Splunk, an internal metrics store) for the time-series data on alert volumes, false-positive rates, detection coverage, and any known events or seasonality markers. This data is serialized into the [TREND_DATA] block. Second, the current threshold configuration is loaded from your detection system's API or configuration store and formatted into [CURRENT_THRESHOLDS]. Third, business constraints—such as maximum tolerable false-positive rate, minimum required detection coverage, and any regulatory requirements—are injected into [BUSINESS_CONSTRAINTS]. The assembled prompt is sent to the model with response_format set to a strict JSON schema that matches the expected output: recommended_thresholds, trend_analysis, impact_projection, and rollback_criteria. On response, the harness must validate the JSON structure, check that recommended values fall within allowed ranges, and confirm that the impact projection includes both alert volume and coverage estimates. Any validation failure should trigger a retry with the error message appended to the prompt, up to a maximum of two retries before escalating to a human operator with the raw model output and validation errors attached.

Human review is mandatory before applying any threshold change. The validated recommendation should be written to a review queue (e.g., a Jira ticket, a Slack message with approval buttons, or a dedicated internal tool) with a clear summary of the proposed changes, the supporting trend analysis, and the projected impact. The review payload must include a diff of the threshold changes, the rollback criteria, and a link to the full model output and input data for auditability. Only after explicit human approval should the harness call the detection system's configuration API to apply the new thresholds. After application, the harness must log the change with a timestamp, the approving user, the prompt version used, and the full model input and output for governance and debugging. Monitor the next cycle's data to verify that the impact projection was accurate; if actual results deviate significantly, trigger a rollback alert and re-queue the prompt for re-evaluation with the new data. Avoid wiring this prompt directly to an automated threshold update—removing the human-in-the-loop gate risks destabilizing your detection pipeline with a single bad recommendation.