End-of-Life Timeline Visualization Prompt

This prompt is designed for technical program managers, API governance teams, and release managers who need to generate consistent, validated timeline representations of end-of-life phases for APIs, SDK methods, or features. It produces text-based timelines that can be embedded in documentation, status pages, or fed into visualization tools. Use this prompt when you have confirmed deprecation dates and need a structured output that enforces chronological consistency across announcement, warning, brownout, and shutdown phases.

The ideal user has already completed the decision-making process for deprecation dates and is now focused on the operational task of communicating those dates in a machine-readable and human-auditable format. The prompt requires a complete set of phase dates as input, including the announcement date, warning date, brownout start and end dates, and the final shutdown date. It will validate that these dates are in strict chronological order and that no phase overlaps or precedes a prior phase. The output is a structured timeline object, not a narrative deprecation notice, making it suitable for ingestion by documentation generators, status page APIs, or internal dashboards.

Do not use this prompt to decide deprecation dates or to draft the surrounding prose of a deprecation notice. It assumes dates are already decided and focuses solely on timeline generation and validation. If you need to draft a customer-facing deprecation notice with migration paths and impact assessments, use the 'API Deprecation Notice Drafting Prompt Template' instead. If you need to classify the severity of a deprecation before building a timeline, use the 'Deprecation Risk Classification Prompt' first. This prompt is a single-purpose tool for turning a set of decided dates into a validated, structured timeline.

This prompt template is designed for technical program managers and API governance teams who need to generate a consistent, visual timeline of a deprecation lifecycle. It accepts structured inputs for each phase—announcement, warning, brownout, and shutdown—and produces a text-based representation, such as an ASCII timeline, a markdown Gantt chart, or a structured JSON object for use in a custom visualization tool. The prompt is built to be pasted directly into an AI system, with square-bracket placeholders that you must replace with your confirmed dates, surface names, and output format preference before execution.

codeCopy
You are a technical documentation assistant. Your task is to generate a text-based timeline visualization for the end-of-life (EOL) process of a product surface.

# INPUT DATA
- Surface Name: [SURFACE_NAME]
- Announcement Date: [ANNOUNCEMENT_DATE]
- Warning Date: [WARNING_DATE]
- Brownout Start Date: [BROWNOUT_START_DATE]
- Shutdown Date: [SHUTDOWN_DATE]
- Replacement Surface: [REPLACEMENT_SURFACE]
- Additional Context: [ADDITIONAL_CONTEXT]

# OUTPUT FORMAT
Generate the timeline in the following format: [OUTPUT_FORMAT]
Options: "ASCII", "Markdown Gantt", "Structured JSON"

# CONSTRAINTS
- All dates must be in YYYY-MM-DD format.
- The timeline must visually represent the progression from announcement to shutdown.
- If the output format is "Structured JSON", use the following schema:
  {
    "surface_name": "string",
    "phases": [
      {"name": "string", "start_date": "YYYY-MM-DD", "end_date": "YYYY-MM-DD"}
    ]
  }
- Do not invent dates or phases not provided in the input.
- If a date is missing or invalid, stop and request clarification instead of guessing.

# VALIDATION
Before generating the final output, perform these checks internally:
1. Confirm all dates are chronologically sequential (Announcement <= Warning <= Brownout <= Shutdown).
2. Confirm all required fields are present.
3. If any check fails, output a clear error message explaining the issue.

To adapt this template, replace the placeholders with your specific data. For [OUTPUT_FORMAT], choose the option that best fits your downstream system. If you select "Structured JSON", you can pipe the output directly into a dashboard or monitoring tool. The internal validation step is critical for high-risk communications; it prevents the AI from generating a timeline with logically impossible dates, which could cause significant confusion for your users. For production use, always have a human review the final output before publication, especially for the shutdown date and replacement surface details.

This prompt is designed to be called programmatically from a release management or API governance system, not used as a one-off chat interaction. The primary integration point is a scheduled job or event-driven trigger that fires when a deprecation decision is approved. The application layer should supply all required inputs—announcement date, warning date, brownout date, shutdown date, and phase descriptions—from a structured deprecation policy record or configuration file. Never rely on the model to invent or infer dates; every date must originate from an authoritative source of truth such as a product roadmap database or an approved deprecation ticket.

Validation pipeline: After the model returns its output, run a deterministic post-processing validator before the timeline reaches any downstream system. The validator must check that (a) all four required phases appear in the output, (b) dates are in strictly increasing chronological order (announcement < warning < brownout < shutdown), (c) each date matches the input dates exactly with no hallucinated offsets, and (d) the output format conforms to the requested schema (ASCII, markdown Gantt, or structured JSON). If validation fails, retry once with an explicit error message injected into the prompt context describing which check failed. If the retry also fails, log the failure, quarantine the output, and escalate to a human reviewer through your deprecation communication approval queue.

Model choice and tool use: This prompt works well with mid-tier models (GPT-4o, Claude 3.5 Sonnet) because the task requires date arithmetic and format consistency rather than deep reasoning. If you are generating structured JSON for a visualization library, set response_format to json_schema (OpenAI) or use tool calling with a strict schema (Anthropic) to enforce field-level type constraints. For ASCII timelines, accept plain text output and validate with regex patterns that confirm the presence of date markers and phase labels. Logging and audit: Every generation should be logged with the input dates, the raw model output, the validation result, and the final approved timeline. This audit trail is essential for deprecation communications, which may be reviewed by legal, compliance, or customer escalation teams months after publication. Store the prompt version, model identifier, and timestamp alongside each generation to support retrospective analysis if a timeline error reaches customers.

Human review gate: Even with perfect validation, all deprecation timelines should pass through a human approval step before publication. The harness should render the generated timeline in a review UI alongside the source dates and any validation warnings. The reviewer confirms that the visual representation matches the intended communication cadence and that no phase is misrepresented. Only after explicit approval should the timeline be published to developer portals, status pages, or email templates. Avoid fully automated publication for any deprecation that affects production APIs or contracted SLAs.