Introduction
The Prompt Template Protocol (PTP) is an open, model-agnostic contract for describing prompts, model targets, and multi-step workflows so they can move cleanly between engines, vendors, and products. This package ships the canonical TypeScript types, Zod validators, and curated examples for the protocol.Model-Agnostic
Works across any LLM provider or platform
Type-Safe
Full TypeScript support with Zod validation
Extensible
Built for growth with optional extensions
Why PTP?
The internet’s most durable protocols—HTTP, TCP/IP, DNS, TLS—earned adoption because they balanced stability with extensibility. They set a small normative core, left space for innovation, and encoded negotiation so legacy clients never broke. PTP 1.1 borrows directly from that DNA.Lessons from the Internet’s Standards
HTTP
HTTP
Clear verbs, consistent status codes, negotiable headers (
Content-Type
, Accept
), and optional features (Keep-Alive
, caching) that gracefully fall back.TCP/IP
TCP/IP
Strict layering and end-to-end reliability while allowing intermediate hops to be ignorant of payload semantics. Versioning happens at the IP header, not in band payload.
DNS
DNS
A compact schema with built-in extension records (EDNS, TXT) that made feature growth possible without rethinking the core lookup flow.
TLS
TLS
Explicit handshake negotiation, cipher suite registries, and version intolerance testing that protects old clients while encouraging new best practices.
Design Commitments
From these protocols we distilled four design commitments for PTP:Stable Core, Optional Surface
Schemas define a normative core while extensions cover vendor-specific features
Explicit Negotiation
Objects can declare version ranges, required capabilities, and optional features before execution
Discoverable Metadata
Rich metadata and links make templates indexable, auditable, and reviewable
Predictable Fallbacks
Workflows describe branching, failure handling, and output contracts for graceful recovery
PTP 1.1 Highlights
1
Semantic Versioning
Semantic version strings on every object (
ptp_version
) for clean negotiation2
Expanded Metadata
Tags, status, license, and links for discoverability and governance
3
Rich Inputs
JSON Schema hints, formats, and examples—mirroring HTTP content negotiation
4
Target Descriptors
Interface, modalities, and constraints so execution engines can map to specific model endpoints
5
Chat-Native Templates
Template parts with roles, media types, and conditional rendering
6
Formal Outputs
Extensions and compliance blocks so downstream tools know what to expect
7
Advanced Workflows
Branching, optional steps, and failure routing inspired by proven orchestration patterns
Installation
Quick Start
TypeScript Usage
Here’s a complete example of a text summarization prompt template:Compile a Prompt Template
The compiler resolves required inputs, applies defaults, evaluates simple conditions, and inline substitutes
{{placeholders}}
. It throws a MissingInputError
, InvalidInputTypeError
, or UnresolvedPlaceholderError
when strict validation fails so you can surface actionable feedback to callers.Validation
The validators enforce semantic version formatting, negotiation bounds, and the richer metadata/extension contracts introduced in v1.1.
Data Model Reference
PromptTemplate
The core structure for defining a prompt template:Semantic version (major.minor[.patch]) - Enables negotiation across tooling
Governance + discovery details including tags, status, links, and lifecycle timestamps
Capability + version handshake - Mirrors TLS/HTTP negotiation to agree on features safely
Inputs with schema hints - JSON Schema snippets improve validation, UI, and documentation
Execution intent - Defines capability, interface, version, parameters, and constraints
Ordered multi-modal prompt parts - Supports chat roles, MIME types, conditional rendering
Named contracts - Downstream systems can bind outputs deterministically
Optional feature modules - Think MIME types or TLS extensions—self-describing and negotiable
Certifications and safeguards - Advertises safety or regulatory posture
Free-form metadata - For analytics, ownership info, or policy hooks
Workflow
Workflows share the sameptp_version
, metadata
, negotiation
, extensions
, and compliance
shapes with additional workflow-specific fields:
Reuses input schema hints for orchestration-layer validation
Now support
description
, condition
, metadata
, and structured on_failure
fallbacksMapping expression that can reference branching logic (e.g.,
step.output || fallback.output
)See concrete JSON specimens in
examples/text-summarizer.json
, examples/image-style-transfer.json
, and examples/blog-creation.json
.Adoption Playbook
For Model Vendors
Advertise Capabilities
Advertise supported
capability
, interface
, and extensions
to enable automated compatibility checksFor Tooling Platforms
Surface Negotiation
Surface negotiation blocks for runtime planning (similar to TLS cipher negotiation dashboards)
For Prompt Engineers
Treat Metadata as Audit Trails
Fill in authorship, lifecycle status, and governance notes for better tracking and accountability
For Security & Compliance Teams
Enforce Standards
Rely on
compliance
to assert safe defaults, and use validators in CI to reject non-compliant templatesKey Features
Version Negotiation
Explicit version ranges and capability requirements ensure compatibility across systems
Rich Metadata
Comprehensive metadata for discoverability, governance, and lifecycle management
Type Safety
Full TypeScript types and Zod validators catch errors at compile time
Multi-Modal Support
Native support for text, images, and other media types in templates
Workflow Orchestration
Define complex multi-step workflows with branching and error handling
Extension System
Modular extension system for vendor-specific features without breaking core compatibility
Best Practices
Always Specify Versions
Always Specify Versions
Use semantic versioning for
ptp_version
and declare minimum_version
in negotiation blocks to ensure compatibility.Provide Rich Metadata
Provide Rich Metadata
Include comprehensive
metadata
with tags, descriptions, and status to make templates discoverable and maintainable.Use JSON Schema for Inputs
Use JSON Schema for Inputs
Define input schemas with validation rules, formats, and examples to improve developer experience and catch errors early.
Document Extensions
Document Extensions
Clearly document any extensions you use and mark them as
required
or optional based on necessity.Handle Failures Gracefully
Handle Failures Gracefully
In workflows, always define
on_failure
handlers to provide predictable fallback behavior.Test Across Providers
Test Across Providers
Validate your templates work across different model providers to ensure true portability.
Examples
Text Summarizer
Learn how to build a production-ready text summarization template
Image Style Transfer
Explore multi-modal templates with image inputs and outputs
Blog Creation Workflow
Build complex multi-step workflows with branching logic
Custom Extensions
Create and integrate custom extensions for specialized use cases
Community & Support
GitHub Repository
View source code, report issues, and contribute
API Reference
Complete API documentation for all types and functions
Migration Guide
Upgrade from PTP 1.0 to 1.1
Contributing
Learn how to contribute to the PTP specification
Next Steps
1
Install the Package
Get started by installing
@potentially/ptp
in your project2
Explore Examples
Review the example templates to understand common patterns
3
Build Your First Template
Create a simple prompt template for your use case
4
Add Validation
Integrate PTP validators into your CI/CD pipeline
5
Share & Collaborate
Publish your templates and contribute to the ecosystem
Ready to standardize your prompt infrastructure?PTP brings the same reliability and interoperability to AI prompts that HTTP brought to the web. Start building portable, maintainable prompt templates today.