Dynamic Serialization Format Prompt Template

This prompt is for data pipeline builders and API gateway teams who need the model to inspect input content and select the most appropriate serialization format before generating the output. Instead of hardcoding a single format, the model analyzes whether the data is nested, tabular, or narrative, then produces JSON, CSV, or Markdown accordingly. The core job-to-be-done is eliminating manual routing logic when your pipeline ingests heterogeneous content and downstream consumers expect format-appropriate payloads. The ideal user is an engineer maintaining an ingestion endpoint that receives unpredictable document structures—think user-submitted reports, scraped pages, or multi-source data feeds—where the shape of the content should drive the output format, not a static configuration flag.

Use this prompt when the content itself is the best signal for format selection. For example, if a user uploads a financial statement with tables, the model should detect the tabular structure and emit CSV. If they submit a product description with nested attributes, JSON is the right call. If they paste a narrative summary, Markdown preserves readability. The prompt includes a format-selection rationale in its metadata envelope, which gives you an auditable decision trail. This is critical when downstream systems need to trust that the format wasn't chosen arbitrarily. Wire this into an API gateway or ETL step where the input content type is unknown at request time, and you need the model to act as an intelligent content-type sniffer before serialization.

Do not use this prompt when the output format is fixed by a strict API contract, when you specifically need XML or YAML output, or when format selection must be determined by an external flag such as a query parameter or an Accept header. In those cases, use a hardcoded serializer or a parameter-driven format switch prompt instead. Also avoid this prompt when the cost of a wrong format choice is catastrophic—if a downstream system will crash on unexpected CSV, you need a deterministic rule, not a probabilistic model decision. For high-stakes pipelines, pair this prompt with a validation harness that confirms the output parses correctly before forwarding, and log the format-selection rationale for debugging. If you need to support additional formats like XML or JSON Lines, extend the [ALLOWED_FORMATS] constraint in the template rather than relying on the model to invent format rules.

This prompt template implements a dynamic serialization router. Instead of hardcoding a single output format, the model inspects the structural characteristics of the provided input and selects the most appropriate serialization format: JSON for nested or hierarchical data, CSV for flat tabular records, or Markdown for narrative or explanatory content. The model must also include a format_selection_rationale in a metadata wrapper, making the decision auditable. Copy the template below, replace the square-bracket placeholders with your specific constraints, and wire the output into a format-specific validator before the response reaches downstream consumers.

textCopy
You are a dynamic serialization engine. Your task is to analyze the provided input and select the single most appropriate output format based on its structural characteristics. You must then produce the output in that format, wrapped in a metadata envelope that explains your choice.

## INPUT DATA
[INPUT]

## FORMAT SELECTION RULES
1.  **JSON**: Select if the input contains nested relationships, hierarchical data, key-value pairs with varying depth, or entities with multiple heterogeneous attributes. Use valid JSON with consistent typing.
2.  **CSV**: Select if the input is a flat list of homogeneous records, a table, or data best represented in rows and columns. Include a header row. Use standard comma delimiters and double-quote escaping.
3.  **Markdown**: Select if the input is primarily narrative text, a document, a conversation, or an explanation that benefits from headings, lists, and prose formatting. Do not force tabular data into Markdown tables if CSV is more appropriate.

## CONSTRAINTS
[CONSTRAINTS]

## OUTPUT ENVELOPE SCHEMA
Your entire response must be a single valid JSON object conforming to this structure:
{
  "selected_format": "json" | "csv" | "markdown",
  "format_selection_rationale": "A brief, specific explanation of why this format was chosen based on the input's structure.",
  "content": "The full generated output in the selected format, serialized as an escaped string. For JSON, stringify the object. For CSV, include newlines. For Markdown, include the raw markdown text."
}

## EXAMPLES
[EXAMPLES]

## FINAL INSTRUCTION
Analyze the [INPUT]. Apply the rules. Output ONLY the specified JSON envelope with no additional text or markdown fences.

To adapt this template, start by populating the [INPUT] placeholder with your data source variable. The [CONSTRAINTS] section is where you enforce domain-specific rules, such as field allowlists, PII redaction requirements, or maximum record counts. The [EXAMPLES] placeholder is critical for ambiguous cases; provide one few-shot example each for a JSON-worthy input, a CSV-worthy input, and a Markdown-worthy input to calibrate the model's structural judgment. After generation, always validate the outer JSON envelope for parse errors and then validate the content string against the schema implied by selected_format before releasing the payload to downstream systems.

The Dynamic Serialization Format prompt is designed to sit inside a data pipeline where the output format must adapt to the structural characteristics of the input content. Unlike a static schema prompt, this template requires the application layer to parse the model's format-selection metadata before routing the payload to the correct downstream validator. The harness must handle three distinct output paths—JSON, CSV, and Markdown—each with its own parsing, validation, and error-recovery logic. A common integration point is an ETL step that receives unstructured or semi-structured text, classifies its shape (nested, flat-tabular, or narrative), and produces a serialized payload that downstream consumers can ingest without manual reformatting.

To implement this reliably, wrap the prompt call in a function that first extracts the format field from the model's metadata envelope. Use a lightweight parser that tolerates minor whitespace variation around the format declaration. Then branch: if format is json, validate the payload against a JSON Schema that matches your expected nested structure and reject or retry on parse errors. If format is csv, validate delimiter consistency, header presence, and column count per row—consider using a library like csv.Sniffer in Python to detect dialect drift. If format is markdown, apply structural checks such as heading hierarchy and table alignment, but accept that Markdown is inherently more permissive. Log every format-selection decision with the input hash, selected format, and validation outcome so you can audit whether the model is choosing appropriately over time. For high-throughput pipelines, add a circuit breaker that falls back to a default format if the model's selection fails validation more than a configurable threshold within a time window.

Retry logic should be format-aware. A JSON parse failure might warrant a single retry with an explicit instruction to fix the JSON structure, while a CSV delimiter inconsistency might be recoverable by re-prompting with dialect hints. Markdown failures are rarely worth retrying at the model level—instead, flag them for human review or downstream normalization. For model choice, prefer models with strong structured output capabilities (such as GPT-4o or Claude 3.5 Sonnet) when JSON or CSV fidelity is critical; lighter models may suffice for Markdown-only paths. If your pipeline serves both internal and external consumers, consider injecting a [CONSUMER_TYPE] variable into the prompt to bias format selection toward machine-parseable outputs for automated systems and human-readable outputs for review dashboards. The most common production failure mode is format-selection mismatch: the model chooses JSON for content that is fundamentally narrative, producing brittle key-value pairs that lose meaning. Mitigate this by running periodic eval suites that compare format appropriateness against human-labeled ground truth for your specific data distribution.