Priority Decay Over Time Scoring Prompt

This prompt is for backlog management systems where priority must increase as items age toward SLA deadlines. It produces a time-decayed priority score by combining an original priority score with an age factor, decay curve parameters, and the item's current position relative to its deadline. Use this when you need deterministic, auditable scoring that controls queue ordering, escalation timing, and resource allocation.

This is not a general-purpose prioritization prompt. It assumes you already have a base priority score and SLA deadline for each item. The prompt applies a decay function to elevate priority as the deadline approaches, making it suitable for operations engineers and support platform builders who need to prevent SLA breaches in large backlogs. Do not use this prompt when you lack a base priority score, when items have no deadline, or when you need to discover priority from unstructured text—use a classification or rubric-based priority prompt instead.

The prompt works best when wired into a scheduled job or event-driven trigger that recalculates scores as time advances. It expects structured input fields: a base score, a creation timestamp, an SLA deadline, and decay parameters. If your system cannot provide these fields deterministically, the prompt will produce unreliable results. Before deploying, validate the decay function against boundary conditions—items exactly at deadline, items past deadline, and items with extreme base scores—to ensure the curve behaves as intended.

The following prompt template implements a deterministic priority decay function. It takes an original priority score, an item's age, and an SLA deadline to produce a new score that increases as the deadline approaches. The template is designed to be used as part of an application harness—not as a standalone chat interaction. Every input is parameterized with square-bracket placeholders that your application must populate before sending the request to the model. The prompt enforces a strict JSON output schema, requires explicit decay curve parameters, and instructs the model to show its work so that every score change is auditable.

textCopy
You are a priority decay scoring function. Your job is to calculate a time-adjusted priority score for a backlog item based on its age, original priority, and SLA deadline. You must follow the decay function specification exactly and return only valid JSON.

## Input
- Original Priority Score: [ORIGINAL_SCORE] (numeric, 0-100)
- Item Creation Timestamp: [CREATED_AT] (ISO 8601)
- Current Timestamp: [CURRENT_TIME] (ISO 8601)
- SLA Deadline Timestamp: [SLA_DEADLINE] (ISO 8601)
- Decay Curve: [DECAY_CURVE] (one of: "linear", "exponential", "step")
- Decay Half-Life (for exponential): [HALF_LIFE_HOURS] (numeric, required if curve is exponential)
- Step Thresholds (for step): [STEP_THRESHOLDS] (JSON array of {hours_remaining: number, multiplier: number}, required if curve is step)
- Maximum Score Cap: [MAX_SCORE] (numeric, default 100)
- Minimum Score Floor: [MIN_SCORE] (numeric, default original score)

## Output Schema
Return exactly this JSON structure with no additional text:
{
  "original_score": number,
  "adjusted_score": number,
  "age_hours": number,
  "hours_until_deadline": number,
  "decay_curve_applied": string,
  "decay_parameters": {
    "curve_type": string,
    "half_life_hours": number | null,
    "step_thresholds_applied": array | null
  },
  "calculation_steps": [
    {
      "step": string,
      "input": number,
      "output": number,
      "explanation": string
    }
  ],
  "cap_applied": boolean,
  "floor_applied": boolean,
  "confidence": "high" | "medium" | "low"
}

## Decay Function Specification
1. Calculate age_hours = (current_time - created_at) in hours.
2. Calculate hours_until_deadline = (sla_deadline - current_time) in hours. If negative, set to 0.
3. Calculate total_sla_window = (sla_deadline - created_at) in hours.
4. Calculate elapsed_ratio = age_hours / total_sla_window, clamped to [0, 1].
5. Apply decay curve:
   - Linear: multiplier = 1 + (elapsed_ratio * (max_score - original_score) / original_score), clamped so adjusted_score never exceeds max_score.
   - Exponential: multiplier = 2 ^ (elapsed_ratio * total_sla_window / half_life_hours), clamped to max_score / original_score.
   - Step: Find the step threshold where hours_until_deadline <= threshold.hours_remaining, apply that multiplier. If no threshold matches, use multiplier 1.0.
6. adjusted_score = original_score * multiplier.
7. Apply cap: if adjusted_score > max_score, set adjusted_score = max_score and cap_applied = true.
8. Apply floor: if adjusted_score < min_score, set adjusted_score = min_score and floor_applied = true.
9. Round adjusted_score to 2 decimal places.
10. Set confidence to "high" if all inputs are valid and calculation is deterministic; "medium" if any input is inferred or estimated; "low" if inputs are missing or contradictory.

## Constraints
- Do not invent missing inputs. If a required input is missing, return an error object: {"error": "Missing required input: [FIELD_NAME]"}.
- Do not apply the decay curve if hours_until_deadline is negative (past deadline). Instead, set adjusted_score = max_score and add a calculation step explaining that the SLA has been breached.
- If original_score is already at max_score, return it unchanged with cap_applied = false.
- All timestamps must be valid ISO 8601. If parsing fails, return an error object.

## Examples
Input: original_score=50, created_at="2025-01-01T00:00:00Z", current_time="2025-01-02T00:00:00Z", sla_deadline="2025-01-03T00:00:00Z", decay_curve="linear", max_score=100
Expected: adjusted_score=75.0, age_hours=24, hours_until_deadline=24, cap_applied=false

Input: original_score=80, created_at="2025-01-01T00:00:00Z", current_time="2025-01-03T12:00:00Z", sla_deadline="2025-01-03T00:00:00Z", decay_curve="linear", max_score=100
Expected: adjusted_score=100.0, hours_until_deadline=-12, cap_applied=true, calculation_steps includes "SLA breached"

Adaptation guidance: Replace each square-bracket placeholder with values from your application's data layer before sending the prompt. The [STEP_THRESHOLDS] placeholder expects a JSON array—your application must serialize this from your configuration store. If your system only supports one decay curve, remove the conditional parameters and hardcode the curve type. For production use, add a [REQUEST_ID] placeholder to correlate model responses with your logging and audit systems. The calculation steps in the output schema are designed to be logged verbatim for debugging and audit trails—do not remove them even if you don't display them to end users.

What to do next: Copy this template into your prompt management system. Build a validation layer that checks the returned JSON against the schema before the score enters your queue ordering logic. Create a set of boundary-condition test cases—items exactly at their SLA deadline, items with zero age, items with original scores at the cap—and run them through the prompt before deploying. If the model returns a confidence of "medium" or "low," route the item to a human reviewer rather than trusting the adjusted score automatically.

The Priority Decay Over Time Scoring Prompt is designed to be called as a stateless function within a larger backlog management or ticket triage system. It expects a structured input containing the original priority score, the item's creation timestamp, the current timestamp, the SLA deadline, and the decay curve parameters. The prompt returns a JSON object with the decayed score, the age factor applied, the decay curve used, and the item's position relative to its SLA window. This output should be consumed by a queue ordering service, a dashboard, or an alerting system—not displayed directly to end users without interpretation.

To wire this into an application, build a thin service wrapper that constructs the prompt payload from your database fields. Validate inputs before calling the model: ensure timestamps are ISO 8601, original scores are within the expected numeric range, and decay parameters (curve type, half-life, floor) are present and valid. After receiving the model response, validate the output schema—check that decayed_score is a number between the configured floor and the original score, that age_factor is positive, and that sla_position (e.g., 'within_window', 'at_risk', 'breached') is one of the expected enum values. If validation fails, retry once with a more constrained prompt that includes the validation error message. If the retry also fails, log the failure, fall back to a deterministic decay calculation using the same curve parameters, and flag the item for human review. This dual-path approach ensures the system never stalls on a malformed model output while still capturing edge cases for prompt improvement.

For model choice, use a fast, inexpensive model (e.g., GPT-4o-mini, Claude Haiku) because the scoring logic is deterministic given the inputs—the model is acting as a calculation engine with explanation, not a creative reasoner. Set temperature=0 to eliminate variance across calls for the same item. Log every scoring event with the input parameters, the raw model response, the validated output, and any fallback path taken. This audit trail is critical for SLA compliance reporting and for debugging scoring anomalies. If your system scores thousands of items per hour, consider batching multiple items into a single prompt call with an array input to reduce API overhead, but keep batch sizes small (5–10 items) to avoid timeout risks and to keep per-item error isolation manageable.

Human review should be triggered when the model's decayed score conflicts with the deterministic fallback calculation by more than a configurable threshold (e.g., 15% difference), when the SLA position is 'breached' but the decayed score hasn't dropped below the escalation floor, or when the model returns an uncertainty_flag indicating ambiguous input. These cases should create a review task in your operations queue with the original inputs, both scores, and the discrepancy highlighted. Do not route decay-scored items directly to customer-facing SLAs without at least a week of shadow-mode validation comparing model-scored priorities against your existing manual or rules-based system.