Transcript of a chat with Perplexity AI on 4 August 2025. Scope:<\/p>\n\n\n\n
The AI cited a range of sources which are not listed here.<\/p>\n\n\n\n
Alec<\/em><\/strong><\/p>\n\n\n\n I\u2019m reading about contract-first prompting. Is this a well known idea?<\/p>\n\n\n\n Perplexity<\/em><\/strong><\/p>\n\n\n\n Contract-first prompting is an emerging approach in the field of prompt engineering for large language models (LLMs), but it is not yet a broadly established or widely recognized term in the AI community. The concept centers on treating the prompt as a contract: before the LLM begins generating output, both the human and the model arrive at a clear, mutual understanding of the task, success criteria, requirements, and constraints\u2014essentially simulating the way engineers or teams agree on specifications before work begins.<\/p>\n\n\n\n The main advocate for this method, as of August 2025, appears to be Nate B. Jones, who describes contract-first prompting as a way to overcome mismatches in intent that often lead to prompt failures. His process involves explicitly communicating the mission, listing out unknowns, having the LLM ask clarifying questions until it is highly confident it understands, and then \u201clocking\u201d the agreement before any generative work starts. This ensures a precision in the model’s output that typical, single-shot instructions often lack<\/a>.<\/p>\n\n\n\n Key features of contract-first prompting include:<\/p>\n\n\n\n While the term \u201ccontract-first\u201d has broader use in software (such as API design<\/a>) and business contract processes, its specific application to prompting LLMs is recent and is only beginning to gain attention outside of Jones’ blog, newsletter, and talks. There are no signs (as of August 2025) that this is a standard technique in mainstream AI literature, though it is being applied practically and seems to be gaining traction among advanced prompt engineers seeking more reliable, aligned outputs from AI models<\/a>.<\/p>\n\n\n\n In summary: Contract-first prompting is a new, not-yet-mainstream idea in LLM prompting, but its principles are resonating with users frustrated by intent failures and iterative prompt re-writing. Its adoption and notoriety may grow as more practitioners experiment with the method and share results.<\/strong><\/p>\n\n\n\n Alec<\/strong><\/em><\/p>\n\n\n\n Having locked the agreement – the contract – how is compliance achieved?<\/p>\n\n\n\n Perplexity<\/strong><\/em><\/p>\n\n\n\n Compliance in contract-first prompting\u2014after \u201clocking\u201d the agreement\u2014relies on both process and mechanisms designed to minimize misunderstanding and enforce the original intent as the model generates outputs.<\/p>\n\n\n\n Here\u2019s how compliance is typically achieved:<\/p>\n\n\n\n 1. Mutually Verified Understanding\u2014Before Execution<\/strong><\/p>\n\n\n\n 2. Process-Driven Output Generation<\/strong><\/p>\n\n\n\n 3. Internal Self-Testing and Critique<\/strong><\/p>\n\n\n\n 4. Human Oversight and Feedback<\/strong><\/p>\n\n\n\n 5. Traceability and Amendments<\/strong><\/p>\n\n\n\n Key Principles for Enforcing Compliance:<\/strong><\/p>\n\n\n\n In sum: Contract-first prompting doesn\u2019t just minimize ambiguity upfront\u2014it supports compliance by converting vague expectations into actionable, checkable commitments, and by making the verification of those commitments part of the generation and review process itself. <\/p>\n\n\n\n This \u201ccontract discipline\u201d borrows best practices from software engineering and project management, tailored to the specifics of LLM interaction.<\/p>\n\n\n\n Alec<\/strong><\/em><\/p>\n\n\n\n Please provide a glossary for the content of this chat.<\/p>\n\n\n\n Perplexity<\/em><\/strong><\/p>\n\n\n\n Here\u2019s a glossary for key terms and concepts related to contract-first prompting, as discussed in this conversation:<\/p>\n\n\n\n Contract-First Prompting<\/strong> Locked Contract \/ Agreement<\/strong> Clarification Loop<\/strong> Echo Check<\/strong> Compliance<\/strong> Self-Testing \/ Self-Critique<\/strong> Rubric<\/strong> Guardrails<\/strong> Iterative Negotiation<\/strong> Prompt Contract<\/strong> Audit Trail<\/strong> Confidence Threshold<\/strong> Token Efficiency<\/strong> These terms form the core vocabulary for understanding and using contract-first prompting as a discipline in language model interactions.<\/p>\n\n\n\n Alec<\/em><\/strong><\/p>\n\n\n\n What does the Prompt Contract comprise, in this approach to working with an LLM?<\/p>\n\n\n\n Perplexity<\/em><\/strong><\/p>\n\n\n\n A Prompt Contract, in contract-first prompting for large language models (LLMs), is a structured, mutually agreed specification between the user and the model that defines exactly what is expected\u2014turning vague intentions into an explicit, checkable work order before any output is generated. Its main components include:<\/p>\n\n\n\n In practice, the Prompt Contract acts as both a plan and a testable checklist. If model output deviates or is incomplete, parties return to the contract to clarify or amend terms, ensuring high accuracy and alignment. This disciplined, engineering-inspired approach is especially useful for high-stakes, complex, or collaborative tasks, reducing intent gaps and making model behavior more predictable and auditable.<\/p>\n\n\n\n Contract-First Prompting Transcript of a chat with Perplexity AI on 4 August 2025. Scope: The AI cited a range of sources which are not listed here. Alec I\u2019m reading about contract-first prompting. Is this a well known idea? Perplexity Contract-first prompting is an emerging approach in the field of prompt engineering for large language models […]<\/p>\n","protected":false},"author":2,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"categories":[],"tags":[7,212],"class_list":["post-571","page","type-page","status-publish","hentry","tag-concept","tag-prompt"],"_links":{"self":[{"href":"https:\/\/anapoly.co.uk\/labs\/wp-json\/wp\/v2\/pages\/571","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/anapoly.co.uk\/labs\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/anapoly.co.uk\/labs\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/anapoly.co.uk\/labs\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/anapoly.co.uk\/labs\/wp-json\/wp\/v2\/comments?post=571"}],"version-history":[{"count":5,"href":"https:\/\/anapoly.co.uk\/labs\/wp-json\/wp\/v2\/pages\/571\/revisions"}],"predecessor-version":[{"id":580,"href":"https:\/\/anapoly.co.uk\/labs\/wp-json\/wp\/v2\/pages\/571\/revisions\/580"}],"wp:attachment":[{"href":"https:\/\/anapoly.co.uk\/labs\/wp-json\/wp\/v2\/media?parent=571"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/anapoly.co.uk\/labs\/wp-json\/wp\/v2\/categories?post=571"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/anapoly.co.uk\/labs\/wp-json\/wp\/v2\/tags?post=571"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n
\n\n\n\n\n
\n
\n
\n
\n
\n
\n\n\n\n
An approach to prompt engineering where both the user and the language model establish an explicit, mutual understanding of the task, requirements, constraints, and deliverables before generating any outputs. The prompt acts as a \u201ccontract\u201d guiding model behavior and evaluation<\/a>.<\/p>\n\n\n\n
The state achieved when both the human user and the language model have fully clarified, summarized, and agreed upon the task and its criteria. Generation begins only after this \u201ccontract\u201d is accepted by both parties<\/a>.<\/p>\n\n\n\n
A process in which the language model asks targeted questions about the prompt or assignment until all gaps or ambiguities are resolved. This loop continues until a certain confidence threshold (e.g., 95%) is achieved, ensuring both parties understand exactly what is required<\/a>.<\/p>\n\n\n\n
A final summary step, where the language model restates the mission or main goal in a single, explicit sentence to confirm mutual understanding. This is usually the step before locking the contract<\/a>.<\/p>\n\n\n\n
The act of ensuring that the model\u2019s outputs adhere to the requirements, constraints, and expectations set out in the locked contract. Compliance involves explicit rubrics, self-testing, and human or model review to verify that the \u201ccontract\u201d is fully honored<\/a>.<\/p>\n\n\n\n
A process where the language model evaluates its own output versus the locked contract, checking for alignment on deliverables, content, tone, and constraints. This may involve specific prompt instructions for the model to \u201cmark its own homework\u201d<\/a>.<\/p>\n\n\n\n
A set of explicit, measurable criteria used to judge whether the model\u2019s output meets the contract. Rubrics can cover required facts, tone, structure, style, and any \u201cmust-not\u201d constraints.<\/p>\n\n\n\n
Rules or boundaries in the contract that keep output within the intended scope, such as stylistic requirements, forbidden content, or strict adherence to facts.<\/p>\n\n\n\n
The process of returning to the clarification loop or contract stage when outputs fail to comply, allowing for further refinement and amendments rather than starting over from scratch<\/a>.<\/p>\n\n\n\n
Another term for the locked prompt; the full, mutually agreed prompt specification defining the agreed work, constraints, and criteria.<\/p>\n\n\n\n
The conversation history, including contract negotiations, clarifications, and amendments. This record provides transparency for how compliance and intent alignment were achieved<\/a>.<\/p>\n\n\n\n
A percentage (such as 95%) representing the degree of certainty the model must reach before locking the contract. Achieved through questions and summarization steps<\/a>.<\/p>\n\n\n\n
The principle of using prompt and process structure (such as contract-first negotiation) to achieve clarity and compliance without relying on excessively long or verbose prompts.<\/p>\n\n\n\n
\n\n\n\n\n
A concise summary of the specific task or objective the model is asked to accomplish. This is the \u201cheadline\u201d of the work assignment and sets the frame for all further instructions<\/a>.<\/li>\n\n\n\n
Explicit details about the output format, length, style, structure, and any other properties the response must have. For example, \u201ca 500-word summary,\u201d \u201cPython code with comments,\u201d or \u201ca list of five strategic recommendations.\u201d<\/a><\/li>\n\n\n\n
Any key pieces of information, facts, or arguments that must appear in the output. These are non-negotiable and serve as the backbone for measuring compliance<\/a>.<\/li>\n\n\n\n
Limitations or boundaries the model should not cross\u2014such as \u201cdo not speculate,\u201d \u201cno first-person language,\u201d \u201cavoid repetition,\u201d or \u201cnever reference X.\u201d Guardrails may also cover tone, audience, or domain-specific restrictions.<\/li>\n\n\n\n
Criteria or checklist for what constitutes a \u201csuccessful\u201d output. This could involve accuracy, completeness, style, tone, or inclusion of certain sections. These criteria become the basis for self-testing or human review of the model\u2019s output<\/a>.<\/li>\n\n\n\n
List of any remaining ambiguities, potential edge cases, or unstated assumptions. These are surfaced and explicitly agreed upon through a clarification loop before locking the contract<\/a>.<\/li>\n\n\n\n
The language model returns a single, crisp summary statement of the agreed task and constraints. The user confirms this matches their intent\u2014at which point, the \u201ccontract\u201d is locked and execution (output generation) can begin<\/a>.<\/li>\n<\/ul>\n\n\n\n
\n","protected":false},"excerpt":{"rendered":"