Recurring Event Rule Normalization Prompt Template

This prompt is for calendar integration engineers and scheduling platform developers who need to convert natural language recurrence descriptions into structured, machine-readable rules. The core job is to take a user-facing string like 'every other Tuesday until the end of the year' and produce a standards-compliant RRULE (RFC 5545), a human-readable confirmation, and a flag for any unsupported patterns. This is a normalization task, not a scheduling engine. The prompt assumes the input is a single recurrence description and the output is a single structured object ready for ingestion into a calendar system or event store.

Use this prompt when you have a reliable natural language input and need a deterministic, validatable output. It is designed for a backend processing pipeline where a user's free-text rule is passed to an LLM before being stored in a database or sent to a calendar API. The prompt includes explicit instructions to validate against RFC 5545, which means it is suitable for systems that must interoperate with standard calendar clients (Google Calendar, Outlook, iCal). Do not use this prompt for generating event instances (expansion), resolving conflicts, or handling complex exception dates. Those are separate scheduling problems that belong in application code, not in a normalization prompt.

Before integrating this prompt, ensure you have a clear contract for what your system considers 'unsupported.' The prompt includes a flag for patterns it cannot normalize, but you must define the boundary. For example, 'every payday' or 'whenever the moon is full' should be flagged, not hallucinated. The next step after reading this playbook is to copy the template, define your [UNSUPPORTED_PATTERNS] list, and run it against a golden test set of 50+ recurrence descriptions that include edge cases like leap year rules, monthly-by-day patterns, and interval limits.

The prompt template below is designed to be dropped into your application's model call. It accepts a natural language recurrence description, optional context like a start date or timezone, and a set of constraints, and returns a structured JSON object containing the normalized RRULE, a human-readable confirmation, and flags for unsupported patterns. All placeholders use square brackets and are meant to be replaced by your application logic before the request is sent to the model.

textCopy
You are a recurrence rule normalization engine. Your job is to convert natural language descriptions of repeating events into RFC 5545 compliant RRULE strings.

## INPUT
Natural language recurrence description:
[RECURRENCE_DESCRIPTION]

Optional context:
- Event start date (ISO 8601): [START_DATE]
- Timezone: [TIMEZONE]
- Known constraints: [CONSTRAINTS]

## OUTPUT SCHEMA
Return ONLY valid JSON matching this schema:
{
  "rrule": "string (RFC 5545 RRULE, or null if unsupported)",
  "human_readable": "string (plain English confirmation of the recurrence pattern)",
  "is_supported": "boolean (false if the pattern cannot be expressed as a standard RRULE)",
  "unsupported_reasons": ["string (list of reasons why the pattern is unsupported, empty if supported)"],
  "warnings": ["string (non-blocking concerns like DST ambiguity, empty if none)"],
  "confidence": "number between 0.0 and 1.0"
}

## RULES
1. Generate RRULE strings compliant with RFC 5545.
2. Use the DTSTART from [START_DATE] if provided; otherwise omit DTSTART from the RRULE.
3. If the recurrence pattern cannot be expressed as a standard RRULE (e.g., 'every last weekday of the month that is not a holiday'), set is_supported to false and leave rrule as null.
4. Include a human_readable confirmation that a non-technical user could verify.
5. Flag any ambiguities in the warnings array (e.g., 'biweekly' could mean twice a week or every two weeks — state which interpretation was used).
6. If the description is vague or incomplete, set confidence below 0.8 and explain in warnings.
7. Do not invent dates, times, or recurrence details not present in the input.

## EXAMPLES
Input: "Every Monday at 9am starting January 6, 2025"
Output:
{
  "rrule": "DTSTART:20250106T090000\nRRULE:FREQ=WEEKLY;BYDAY=MO",
  "human_readable": "Every Monday at 9:00 AM starting January 6, 2025",
  "is_supported": true,
  "unsupported_reasons": [],
  "warnings": [],
  "confidence": 0.98
}

Input: "Every other Tuesday and Thursday until December"
Output:
{
  "rrule": "DTSTART:20250101T000000\nRRULE:FREQ=WEEKLY;INTERVAL=2;BYDAY=TU,TH;UNTIL=20251231T235959",
  "human_readable": "Every other week on Tuesday and Thursday until December 31, 2025 (assuming start date of January 1, 2025 and end of December)",
  "is_supported": true,
  "unsupported_reasons": [],
  "warnings": ["Start date not provided, assumed January 1, 2025", "End date not specified, assumed December 31, 2025"],
  "confidence": 0.75
}

To adapt this template for your system, replace each square-bracket placeholder with values from your application context. The [RECURRENCE_DESCRIPTION] field should contain the raw user input or natural language text. [START_DATE] and [TIMEZONE] should be injected from your event or calendar record when available. The [CONSTRAINTS] field can carry business rules such as 'no weekend events' or 'only future dates'. If your application already has a known output schema, replace the JSON schema block with your own contract. For high-volume production use, add a post-processing step that validates the RRULE string against an RFC 5545 parser before storing it, and log any outputs where is_supported is false or confidence falls below your threshold for human review.

This prompt is designed to sit inside a post-extraction normalization layer, not as a direct user-facing chatbot. The typical caller is a calendar integration service, a scheduling API backend, or a data ingestion pipeline that has already extracted a natural language recurrence description from an email, a meeting transcript, a booking form, or a legacy system export. The caller should pass that extracted text as [RECURRENCE_DESCRIPTION] along with an optional [ANCHOR_TIMESTAMP] to resolve relative references like 'every other Monday starting next week.' The prompt returns a structured JSON payload containing a validated RRULE string, a human-readable confirmation, and an unsupported_patterns flag. Do not use this prompt for real-time chat interactions where the user is iteratively refining a recurrence rule; a multi-turn interface with a structured recurrence builder is more appropriate for that use case.

Wire the prompt into a stateless async worker or a request-response API endpoint. The application layer should enforce a strict JSON schema on the model's response before it reaches any downstream system. If the response fails schema validation—missing required fields, malformed RRULE syntax, or a normalized_rrule that does not parse as valid RFC 5545—the harness should retry once with the validation error injected into the [PREVIOUS_ERRORS] placeholder. After a second failure, log the full input, output, and validation trace, then route to a human review queue. For high-volume pipelines, consider batching multiple descriptions into a single request with a JSON array input and a corresponding array output schema to reduce API overhead, but keep batch sizes small (5-10 items) to avoid confusing the model across unrelated recurrence patterns.

Model choice matters here. Use a model with strong code and structured output capabilities, such as gpt-4o, claude-3-5-sonnet, or an equivalent. Avoid smaller or older models that may hallucinate RRULE property names or mishandle BYDAY ordinal values. Set temperature=0 to maximize deterministic RRULE generation. Enable structured outputs or JSON mode if the provider supports it, and always validate the RRULE string against an RFC 5545 parser library (such as rrule.js or dateutil.rrule in Python) before persisting the result. The unsupported_patterns field is a critical safety valve: if the model flags a pattern as unsupported, your application must not silently drop it. Instead, store the original description alongside the flag and surface it in an admin review interface so a human can author the correct RRULE or decide on an alternative representation.

For observability, instrument the harness with metrics on validation pass rate, retry rate, unsupported pattern frequency, and human review queue depth. Log every input description, the generated RRULE, the human-readable confirmation, and the validation result. This trace data is essential for debugging edge cases—such as 'every last weekday of the month' or 'biweekly on the 31st'—that may parse correctly but produce unexpected scheduling behavior. Set up a periodic eval run against a golden dataset of 50-100 recurrence descriptions with known-correct RRULE outputs, including tricky cases like monthly-by-day with skip logic, yearly patterns with timezone-aware exclusions, and descriptions that contain contradictory constraints. Run this eval on every prompt version change and on every model provider upgrade to catch regressions before they affect production calendars.