XML Document Structure Prompt for Enterprise Feeds

This prompt is built for integration engineers and AI platform architects who need a large language model to produce a complete, valid XML document that can be consumed directly by a downstream enterprise system without a post-processing repair step. The core job-to-be-done is transforming a set of structured or semi-structured inputs—such as a purchase order, a financial transaction log, or a compliance report—into a well-formed XML payload that adheres to a specific schema, namespace, and encoding declaration. The ideal user is someone who already has an XML-based contract with an existing system and needs the model to act as a reliable translator, not a creative writer. Required context includes the target XML Schema Definition (XSD) or a representative sample document, the root element name, the namespace URI, and any processing instructions the receiving system expects.

Use this prompt when the cost of a malformed output is high. If a missing closing tag, an incorrect namespace prefix, or an unescaped ampersand in a CDATA section would break an order management feed, corrupt a financial transaction log, or fail a compliance audit, the precision of this prompt is warranted. It is designed for XML-first enterprise environments where the output must survive an XML schema validation step before any business logic is applied. This prompt is not for generating HTML, Markdown, or JSON. It is not a general-purpose document formatter. If your downstream system can accept JSON, use a JSON schema enforcement prompt instead; the tooling and model support for JSON are more mature, and you will spend less effort on validation and repair.

Before using this prompt, confirm that you have a strict, machine-readable schema or a set of unambiguous structural rules. If your XML requirements are loosely defined or vary significantly per transaction, this prompt will be brittle. In those cases, consider a two-step pipeline: first, use a structured object generation prompt to produce a typed object, then use a deterministic serializer to convert that object to XML. This prompt is a precision tool for environments where the XML structure itself is the contract, and you are ready to invest in schema validation, retry logic, and human review for high-risk transactions.

The following prompt template is designed for integration engineers who need a model to produce valid, parseable XML documents for downstream enterprise systems. It enforces root element declaration, namespace consistency, attribute ordering, encoding declarations, and CDATA section placement. The template uses square-bracket placeholders that you replace with your specific schema, data, and constraints before sending the prompt to the model.

textCopy
You are an XML generation engine. Your only output must be a single, well-formed XML document that parses without errors.

## Input Data
[INPUT_DATA]

## Target Schema (XSD or DTD reference)
[SCHEMA_DEFINITION]

## Output Requirements
1. The root element must be <[ROOT_ELEMENT]> with the namespace declaration xmlns="[NAMESPACE_URI]".
2. Encoding declaration <?xml version="1.0" encoding="[ENCODING]"?> must appear on the first line with no preceding whitespace.
3. All elements must be properly nested and closed. Self-closing tags are permitted only where the schema allows empty elements.
4. Attributes must appear in this order: [ATTRIBUTE_ORDER]. Use double quotes for all attribute values.
5. Text content that contains <, >, &, ", or ' characters must be wrapped in <![CDATA[...]]> sections. Do not use entity references inside CDATA.
6. Entity references (&lt; &gt; &amp; &quot; &apos;) are permitted only outside CDATA sections.
7. Comments are allowed only in these locations: [COMMENT_LOCATIONS].
8. The document must validate against the provided schema. Check element cardinality, required attributes, and enumeration constraints.
9. Output only the XML document. No markdown fences, no explanatory text, no preceding or trailing whitespace beyond the XML declaration.

## Constraints
- [ADDITIONAL_CONSTRAINTS]

## Examples of Valid Output Structure
[VALID_EXAMPLES]

## Examples of Invalid Output (do not produce these)
[INVALID_EXAMPLES]

To adapt this template, replace each bracketed placeholder with concrete values from your integration specification. For [SCHEMA_DEFINITION], include the full XSD or a summarized version with element names, types, cardinality, and enumeration values. For [VALID_EXAMPLES], provide at least two complete XML documents that match your schema, covering both simple and nested cases. For [INVALID_EXAMPLES], show common failure modes such as missing namespace declarations, incorrect attribute ordering, or unescaped special characters outside CDATA. If your downstream system requires specific whitespace handling or indentation rules, add those to [ADDITIONAL_CONSTRAINTS]. Before deploying, run the output through a standard XML parser and your schema validator. If the validation failure rate exceeds 5% in testing, add more explicit examples or break the generation into smaller, schema-verified chunks.

This prompt is designed to be the final generation step before an XML document enters an enterprise integration pipeline. It should not be called in isolation. The application layer must supply the [SCHEMA], [ROOT_ELEMENT], [NAMESPACES], and [CONTENT_DATA] variables from a trusted source of truth, never from raw user input. The model's job is structural assembly and entity escaping, not content authorization. Treat the prompt as a structured serializer: it turns a validated data object into a compliant XML string. The application, not the model, owns the business rules about what data is allowed in the feed.

Wire the prompt into a pipeline with three stages: pre-generation validation, model invocation, and post-generation verification. In the pre-generation stage, validate [CONTENT_DATA] against the same schema you will use to validate the output. This catches data problems before they become XML problems. For model invocation, use a low-temperature setting (0.0–0.2) to maximize structural consistency. If your platform supports it, set the response_format to text and disable any JSON mode that might interfere with angle-bracket generation. Log the full prompt, model response, and any validation errors to an audit table for debugging encoding or namespace drift over time.

Post-generation verification is non-negotiable. Parse the model's output with a strict XML parser (such as lxml or javax.xml.parsers) configured to reject documents that are not well-formed. Then validate against the provided [SCHEMA] using an XSD validator. If validation fails, do not retry more than twice. On the first retry, append the validation error message to the prompt as a [PREVIOUS_ERROR] variable and ask the model to correct only the specific violation. On the second failure, log the incident, capture the malformed output, and escalate to a human review queue. Never silently fall back to a best-effort XML string in production.

For high-stakes feeds such as financial reporting, healthcare data interchange, or regulatory filings, add a human approval gate after successful validation. The system should render the validated XML in a review interface with a diff against the previous feed version, highlight namespace changes, and require explicit sign-off before transmission. This gate protects against semantically valid but contextually wrong output, such as a correctly structured invoice with an incorrect total that passed schema checks. The model can guarantee structure; the application and its operators must guarantee correctness.