Prompt Declaration Language (PDL)

• Prompt Declaration Language (PDL) is a family of formal declarative languages that uses structured YAML/DSL to specify and manage prompts for LLMs and related systems.
• It employs a modular methodology by separating provenance, constraints, task content, and post-evaluation to ensure clarity and rigorous compliance.
• PDL supports automated optimization, lifecycle governance, and integration with advanced LLM architectures to mitigate drift and enhance prompt efficiency.

Prompt Declaration Language (PDL) refers to a family of formal, declarative languages, frameworks, and meta-schemas engineered for specifying, controlling, and analyzing prompts—both for LLMs and, in some domains, for hardware or processor description. In the context of modern AI, PDL is most prominently a YAML- or DSL-based declarative language to structure, manage, and optimize prompts, prompt-execution pipelines, and agentic behaviors under evolving LLM platforms. It is distinguished from ad hoc prompt engineering by its formal grammars, explicit separation of declarative modules, and its amenability to static analysis, automated optimization, and lifecycle governance. This article surveys foundational definitions, syntactic and semantic structure, compliance protocols, use cases, architectural roles, optimization workflows, and the comparative landscape.

1. Foundations and Formal Grammar

PDL’s core principle is modular declarativity: prompts are specified as composable, statically analyzable data structures with clear semantics. In leading PDL instantiations for LLMs—such as those introduced by Vaziri et al. and in NLD-P—the canonical representation is a YAML-based language whose syntax captures not only prompt-content, but also context metadata, constraint logic, evaluation rules, and tool/LLM invocation structure (Vaziri et al., 8 Jul 2025, Vaziri et al., 2024, Kim et al., 26 Feb 2026).

A representative formal grammar (LaTeX BNF, (Kim et al., 26 Feb 2026)) defines a PDL prompt as:

$$\begin{array}{rcl} \langle Prompt\rangle &::=& \langle Provenance\rangle\;\langle ConstraintBlock\rangle\;\langle TaskContent\rangle\;\langle PostEval\rangle \ \langle Provenance\rangle &::=& [\mathrm{IDENT}]\;\langle KVPair\rangle^+ \ \langle ConstraintBlock\rangle &::=& [\mathrm{RULE}]\;\langle Constraint\rangle^+ \ \langle TaskContent\rangle &::=& [\mathrm{CONTENT}]\;\mathtt{NaturalLanguageTask} \ \langle PostEval\rangle &::=& [\mathrm{POSTCHECK}]\;\mathtt{EvaluationRule}^+ \ \end{array}$$

The typical PDL 4-tuple structure is:

• $P$ (Provenance): metadata including schema, assistant identity, mode, version.
• $C$ (ConstraintLogic): constraints enforced on prompt execution (e.g., style, format).
• $T$ (TaskContent): the primary, human-readable task or instruction.
• $E$ (PostEval): post-generation evaluation, quality checks, revision triggers.

Typed, schema-based representations in JSON Schema are provided for validation and interpreter enforcement (Kim et al., 26 Feb 2026, Vaziri et al., 2024). The grammars extend to include function definitions, block control flow, structured I/O types, and (in some PDLs) SQL-inspired context selection, token budget enforcement, and modular prompt “subqueries” (Gong, 23 Feb 2026).

2. Minimal Compliance and Structural Protocols

PDL enforces minimal compliance criteria for prompt definitions (Kim et al., 26 Feb 2026):

1. Structural separation: Each module (Provenance, Constraints, TaskContent, PostEval) must be non-empty and structurally distinct.
2. Precedence ordering: Modular blocks must appear in prescribed order: $(P,C,T,E)$.
3. Constraint independence: $C$ must not reference $T$ or $E$; constraints are decoupled from content and evaluation.
4. Evaluation declared ex ante: All evaluation rules must be external to task content.

Violation—such as interleaving constraints and evaluation in task text—renders a prompt non-compliant. This modularization is not mere style, but foundational to prompt governance, interpretability, and drift resilience under LLM change (Kim et al., 26 Feb 2026).

3. Architecture, Execution, and Integration

PDL is typically backed by an interpreter or compiler that parses YAML-based (or DSL) prompt definitions, executes block-by-block, manages message context, and enforces typing and role schema (Vaziri et al., 2024, Vaziri et al., 8 Jul 2025). The architecture orchestrates:

• Prompt parsing and expansion (YAML to IR/data structures)
• Runtime context management: Sequential accumulation of user/assistant/system blocks as prompt context.
• Model/tool invocation: Direct calls to LLM backends, with optional structured output parsing (JSON Schema, constrained decoding).
• Control flow and composition: If/for/repeat blocks, composable definitions, and external code blocks for tool integration.
• Evaluation and compliance: Runtime enforcement of output structure, explicit evaluation rules from $E$.

Advanced platforms support modular inclusion/import, Jinja2 templating, dynamic code blocks with Python or other host language execution, and integration with SDKs, IDE plugins, and batch/stream execution modes (Vaziri et al., 2024, Vaziri et al., 8 Jul 2025). The structured representation of prompts also enables external optimization and meta-programming (Spiess et al., 6 Apr 2025).

4. Modularity, Governance, and Lifecycle Management

PDL modularity enables localized edits, porting, and automated repair in response to LLM drift:

• Schema extension: New constraints or evaluation rules added to $P$0 or $P$1 do not retroactively alter task $P$2 or provenance $P$3.
• Model drift mitigation: Lightweight revision of $P$4 adapts to evolving decoding, alignment, or instruction-following in target LLMs. Failure in $P$5 surfaces model-dependent brittleness, directing governance effort (Kim et al., 26 Feb 2026).

The lifecycle workflow emphasizes human-in-the-loop control (Kim et al., 26 Feb 2026):

1. Specification: Draft $P$6, $P$7, $P$8, $P$9.
2. LLM Drafting: Assistant executes under declared governance schema.
3. Human Review/Revision: SME inspects individual blocks and outputs, applies corrections.
4. Final Approval: Only after compliance and quality review is the prompt or agentic workflow deployed.

PDL’s lifecycle model ensures auditability and stability regardless of model/provider evolution—a property critical as LLM APIs and backends shift across time.

5. Prompt Patterns, Optimization, and Agentic Programming

PDL exposes, defines, and allows source-level search over canonical prompt patterns—including Zero-Shot, Chain-of-Thought (CoT), ReAct, and ReWOO (Spiess et al., 6 Apr 2025). Pattern libraries are implemented as first-class reusable defs: or modules, parameterizable by system prompt, demonstrations, tools, and task—in effect compositional templates. This exposes prompting strategies to AutoML-style optimization, as in AutoPDL (Spiess et al., 6 Apr 2025), where a structured space of PDL candidates is pruned via successive halving or other search strategies to identify performant prompt-agent configurations.

PDL supports:

• Fine-grained prompt tuning: Control over turn-wise NL/text and action specification, decoupling “thought” and “action” blocks (Vaziri et al., 8 Jul 2025).
• Programmatic agent construction: Direct encoding of agent loops, retrieval-augmented generation, external tool calls, and observation handling via declarative blocks.
• Structured output enforcement: JSON Schema and parser combinators for safe tool-calling, reducing invalid output.
• Manual + automated tuning: Both hand-crafted and automatically “compiled” (optimized) PDL programs, with human-in-the-loop editing supported end-to-end (Spiess et al., 6 Apr 2025).

6. Comparative Landscape and Extensions

PDL is positioned against major prompt programming paradigms along axes of declarativity, compositionality, and execution model:

Framework	Declarative	Compositional Patterns	Host-Language Free	Constrained Decoding	LLM Agnostic
PDL (YAML, DSL)	Yes	Yes	Yes	Yes (schema-based)	Yes
LangChain, AutoGen	Partial	Yes (API-level)	No	No	Partial
Guidance, LMQL, SGLang	Partial	Partial	No	Yes (token-level)	Yes
DSPy, Vieira	Yes	Limited (opaque)	Yes	No	Yes

PDL is further extended in SPL (Structured Prompt Language), which applies SQL-like query semantics, explicit token budgeting, explainable token allocation, provider-agnostic orchestration, mixture-of-models routing, and agentic pipeline composition (SPL-flow) (Gong, 23 Feb 2026). These extensions demonstrate the scalability of the PDL paradigm to resource management, multi-model inference, and explainable prompt execution.

7. Alternative Domains: Processor Description Language (PDL) and Propositional Dynamic Logic

The abbreviation PDL occurs in unrelated but notable domains:

• Processor Description Language (VADL): A statically-typed DSL for formal processor architecture specification, separates instruction set (ISA) and microarchitecture (MiA), and generator-based artifact production (assembler, compiler, simulator, hardware) (Freitag et al., 2024).
• Propositional Dynamic Logic (PDL): A modal logic for program verification, expressively equivalent to the bisimulation-invariant fragment of FO(TC¹). Not related to language-model prompt management; included for terminological disambiguation (Carreiro, 2015).

• "Representing Prompting Patterns with PDL: Compliance Agent Case Study" (Vaziri et al., 8 Jul 2025)
• "PDL: A Declarative Prompt Programming Language" (Vaziri et al., 2024)
• "Natural Language Declarative Prompting (NLD-P): A Modular Governance Method for Prompt Design Under Model Drift" (Kim et al., 26 Feb 2026)
• "AutoPDL: Automatic Prompt Optimization for LLM Agents" (Spiess et al., 6 Apr 2025)
• "Structured Prompt Language: Declarative Context Management for LLMs" (Gong, 23 Feb 2026)
• "SPML: A DSL for Defending LLMs Against Prompt Attacks" (Sharma et al., 2024)
• "The Vienna Architecture Description Language" (Freitag et al., 2024)
• "Characterization theorems for PDL and FO(TC)" (Carreiro, 2015)