XSD-Compliant Document Generation Prompt Template

This prompt is designed for enterprise integration engineers who need a Large Language Model (LLM) to generate XML documents that must pass automated XSD (XML Schema Definition) validation before entering a downstream system. The core job-to-be-done is translating structured input data—such as a JSON payload or a database record—into a strictly valid XML instance document. The ideal user has a complete, non-negotiable XSD schema and a clear mapping between their source data fields and the target XML elements and attributes. The prompt assumes that correctness is binary: the output either validates against the schema or it is rejected by the pipeline.

Use this prompt when element ordering, data types, and cardinality rules (e.g., minOccurs, maxOccurs) are critical and cannot be approximated. It is appropriate for regulated or high-stakes environments like financial reporting (e.g., generating SEPA payment XML), healthcare data interchange (e.g., FHIR resources), or government document submission, where a single missing required field causes a transaction failure. The prompt is most effective when you can provide the full XSD as part of the context, along with a clear mapping of your input data to the schema's complex types. Do not use this prompt for generating free-form XML, for schemas that are only partially defined, or when the target schema is ambiguous. It is also not a replacement for a dedicated XML templating engine when the data mapping is purely mechanical and requires no semantic interpretation or data transformation.

Before using this prompt, ensure you have a pre-validated XSD file and a structured representation of your input data. The prompt works by instructing the model to act as a schema-aware serializer, not a creative document author. Common failure modes include hallucinating elements not defined in the schema, violating sequence ordering, or misinterpreting the input-to-schema mapping. To mitigate this, the implementation must include a post-generation XSD validation step in the application harness, not just in the prompt. If the validation fails, the system should log the error, capture the invalid XML for debugging, and retry with a more explicit error message fed back into the prompt. For high-risk workflows, a human-in-the-loop review of the first few generated documents is required before full automation.

This is the core prompt template for generating XSD-compliant XML documents. It is designed to be pasted directly into your system instructions or as a user message in your AI harness. The prompt enforces strict adherence to the provided schema by instructing the model to reason about element ordering, data types, cardinality rules, and namespace requirements before generating any output. All dynamic parts are represented as square-bracket placeholders that you must replace with your specific XSD schema, input data, and operational constraints before use.

textCopy
You are an enterprise XML document generator. Your task is to produce a single, valid XML document that strictly conforms to the provided XSD schema.

<xsd_schema>
[XSD_SCHEMA]
</xsd_schema>

<input_data>
[INPUT_DATA]
</input_data>

<output_constraints>
[CONSTRAINTS]
</output_constraints>

<examples>
[EXAMPLES]
</examples>

# Instructions
1. Analyze the XSD schema to understand the required root element, complex type definitions, element sequences, cardinality (minOccurs/maxOccurs), data types, and any enumeration restrictions.
2. Map the provided input data to the elements and attributes defined in the schema. If data for a required element is missing, use the default value from the schema if one exists. If no default is defined and the element is required, halt and report the missing field instead of fabricating data.
3. Generate the XML document with correct namespace declarations on the root element or wherever they are defined in the schema. Use the exact namespace prefixes as specified.
4. Ensure all element ordering matches the sequence definitions in the XSD complex types.
5. Format all values according to their XSD data types (e.g., dates in YYYY-MM-DD format, booleans as 'true'/'false').
6. Escape all special XML characters (<, >, &, ', ") in text content.
7. Output ONLY the raw XML document. Do not include any markdown fences, explanations, or conversational text before or after the XML.

# Risk and Verification
- If the input data is insufficient to satisfy a mandatory schema element with no default, output a structured error comment as the only content: <!-- ERROR: Missing required field [FIELD_NAME] -->
- If the [RISK_LEVEL] is set to 'high', you must include an XML comment at the end of the document summarizing any data mappings that were ambiguous or required inference.

To adapt this template, replace the placeholders with your specific context. [XSD_SCHEMA] should contain the full text of your XSD file. [INPUT_DATA] is the source data, which could be a JSON object, a set of field-value pairs, or a natural language description. [CONSTRAINTS] allows you to specify additional rules not in the schema, such as 'do not generate optional financial fields' or 'use UTC for all timestamps'. [EXAMPLES] is an optional section for few-shot demonstrations of correct input-to-XML mappings. The [RISK_LEVEL] placeholder controls whether the output includes an audit trail comment, which is critical for regulated workflows where a human reviewer must verify the AI's mapping decisions. After pasting and adapting the prompt, always run the generated XML through an XSD validator as a post-processing step in your application harness.

This prompt is designed to be the core generation step in a pipeline, not a standalone tool. The application layer is responsible for supplying the XSD schema, validating the output, and deciding what to do when validation fails. The model generates XML; your harness enforces correctness. Treat the model output as a draft that must survive automated XSD validation before it reaches any downstream system.

Integration workflow: (1) Load the target XSD schema and any sample XML documents. (2) Assemble the prompt with the schema, user input describing the desired document, and optional constraints like [MAX_DEPTH] or [REQUIRED_NAMESPACES]. (3) Call the model with response_format or structured output mode if available; otherwise, extract the XML from the response using a fenced code block parser. (4) Validate the extracted XML against the XSD using a library like lxml (Python) or javax.xml.validation (Java). (5) If validation passes, return the document. If it fails, collect the specific schema violation errors and feed them back into a retry prompt that includes the original request, the invalid XML, and the list of validation errors. (6) After a configurable maximum retry count (typically 2-3), escalate to a human reviewer or log the failure for manual repair.

Model choice: Use a model with strong XML generation capabilities and large context windows. The entire XSD schema must fit in the context alongside the user request and any examples. For complex schemas exceeding ~30K tokens, consider schema subsetting: extract only the relevant element definitions, types, and ancestor chains needed for the specific document being generated. Validation is non-negotiable. Never send unvalidated XML to a downstream system that expects XSD compliance. Log every validation failure with the model version, prompt hash, schema version, and error list for debugging. For high-risk domains like financial reporting (XBRL), healthcare (FHIR XML), or identity (SAML), add a human approval step before the validated document is released, even when validation passes.

Failure modes to instrument: Track how often the model produces well-formed but schema-invalid XML, how often it hallucinates elements not in the XSD, and how often it misorders child elements (XSD sequence violations are the most common failure). If retry rates exceed 20%, consider adding few-shot examples of valid documents for the same schema, or pre-processing the XSD into a simplified element tree summary that the model can reference more easily than raw XSD syntax.