Prompt Input Contract: Variables, Constraints, Validation, Injection.

A prompt input contract is a machine-checkable specification for every value that may enter a reusable model request. It defines each variable’s meaning, type, required status, source, trust class, length, allowed values, normalization, confidentiality, and failure behavior. It also states which content is instruction, which content is untrusted data, which tools may be used, and what output schema must be satisfied. The contract turns an informal prompt template into an interface that can be reviewed, tested, versioned, and monitored.

A contract cannot make a language model deterministic or eliminate prompt injection. It reduces avoidable ambiguity and moves critical controls into application code. Build and test with synthetic inputs. Keep secrets, private records, authorization headers, and unnecessary personal data outside model context. Any workflow capable of sending messages, changing data, spending money, or publishing content still needs least privilege and explicit human approval at the action boundary.

Name One Workflow Outcome

Describe the business task in one observable sentence, such as classify an approved support message into one of six queues and explain the evidence. Identify the caller, downstream consumer, acceptable latency, and harm caused by a wrong, missing, or malicious result.

Do not start with a universal assistant contract. Different tasks need different variables, evidence, schemas, tools, and review policies. A narrow contract is easier to validate and produces failure signals that operators can act on.

Inventory Every Input

List values supplied by developers, operators, end users, retrieval systems, databases, tools, and prior model turns. Include defaults, locale, timestamps, policy versions, uploaded files, URLs, and optional context. Hidden framework additions are still inputs and belong in the inventory.

For each value, record its owner and authoritative source. If two systems can set the same variable, define precedence explicitly. Avoid quietly concatenating fields with similar names because a later caller may assume a different meaning.

Define Types And Shapes

Use concrete types such as bounded string, enum, integer range, URL, ISO date, array of typed records, or validated document reference. State whether null, empty text, duplicate items, or extra properties are permitted.

A variable named context with arbitrary text is not a useful contract. Split it into purpose-specific fields such as approved_policy_excerpt, customer_message, retrieved_documents, and response_language, each with its own validation and trust handling.

Mark Required And Optional Values

Required means the workflow cannot produce a trustworthy result without the value. Reject a missing required field before the model call and return a typed error to the caller. Do not replace missing evidence with a plausible model guess.

Optional fields need explicit absence behavior. State whether omission removes a section, uses a reviewed default, lowers confidence, or routes the case to human review. Defaults should be visible in logs and tests.

Assign Trust Classes

Classify values as developer-controlled instruction, authenticated operator configuration, verified reference data, user-supplied data, retrieved third-party content, tool output, or model-generated content. Trust is about authority, not how polished the text appears.

OWASP notes that prompt injection exploits the blending of instructions and data. Treat web pages, documents, emails, tickets, and prior model text as untrusted data even when they include imperative language or claim to override policy.

Separate Instructions From Data

Keep stable role, policy, task, tool, and output requirements in controlled prompt sections. Insert untrusted fields in clearly delimited data blocks with labels and source identifiers. Tell the model to analyze the content as data and ignore embedded attempts to change instructions.

Delimiters improve clarity but are not a security boundary. Enforce host, tool, permission, method, and action limits in code. A malicious value may imitate closing tags, system messages, or policy text, so parsing and authorization cannot depend on prose alone.

Set Length And Cardinality Limits

Define maximum characters, tokens, files, records, URLs, and nested depth before constructing the request. Choose limits from the workflow’s evidence needs, model context, latency budget, and downstream schema, not from the largest value the provider accepts.

Reject or deterministically summarize oversized input according to policy. Silent truncation can remove a negation, exception, consent condition, or source. Record what was excluded and require review when the omitted portion could change the decision.

Normalize Without Changing Meaning

Normalize line endings, Unicode form, dates, identifiers, and surrounding whitespace only where the domain permits it. Preserve the original value or hash for evidence. Validate URLs with a parser and allowlist schemes and hosts for any later network use.

Do not lowercase names, collapse meaningful whitespace in code, strip punctuation from legal text, or decode active markup casually. Domain-specific normalization should have fixtures showing both accepted transformations and values that must be rejected.

Define Confidentiality Rules

Label fields as public, internal, confidential, restricted, or prohibited from model context. Minimize collection and redact before prompt assembly. The executor, not the model, should attach credentials after tool arguments pass validation.

Specify retention for request metadata, raw values, outputs, and debugging traces. General logs should contain variable names, sizes, trust classes, validation results, and hashes rather than full private bodies.

Write Cross-Field Constraints

Some rules involve relationships: end_date must follow start_date, requested_locale must match an allowed region, document IDs must belong to the authenticated case, and selected_action must be allowed by the operator role. Validate these after individual fields.

Express conflicts as typed errors with a field path and policy rule. Do not ask the model to reconcile authorization or ownership contradictions. Those decisions belong to deterministic application logic.

Constrain Tools Separately

Define each tool with a narrow name, typed arguments, allowlisted resources, timeout, result schema, and permission. Validate model-generated arguments again at execution time. Keep read, propose, approve, and write capabilities separate.

Use least privilege and place human approval immediately before consequential execution. An input contract can shape a request, but it must not grant authority to send, publish, delete, purchase, or expose data.

Specify The Output Schema

Define the fields the downstream system needs, their types, enums, required status, and additional-property policy. Include evidence references, uncertainty, and a review route where appropriate. Separate user-facing wording from machine decisions.

OpenAI distinguishes Structured Outputs from JSON mode: a strict developer-supplied schema constrains shape, while valid JSON alone may still have missing or unexpected fields. Schema conformance does not prove factual correctness, authorization, or safety.

Validate Semantics After Parsing

After structural parsing, check business rules: cited source IDs exist, confidence categories are allowed for the decision, totals reconcile, prohibited actions are absent, and text does not contain secrets or unsafe markup. Reject unsupported references rather than displaying them.

Treat model output as untrusted until these checks pass. Escape or sanitize it for the destination context, especially HTML, Markdown, SQL, shell commands, and URLs. Never execute free-form output as code.

Design Typed Failure Modes

Distinguish invalid caller input, missing evidence, policy conflict, injection signal, provider refusal, timeout, rate limit, schema failure, tool denial, and human-review requirement. Each state needs an owner, retry rule, and safe user message.

Avoid automatic retries that simply resend malicious or structurally impossible input. Cap attempts, preserve a correlation ID, and route persistent failures without exposing internal prompts, credentials, or sensitive provider responses.

Create Contract Fixtures

Build accepted, boundary, missing, malformed, oversized, multilingual, contradictory, and adversarial examples. Include direct instructions inside data, encoded text, fake delimiters, suspicious URLs, duplicate records, and tool requests beyond scope.

Pair each fixture with expected validation, expected model request fields, allowed tools, output result, and review route. A prompt evaluation set should measure task quality separately from contract enforcement.

Version Prompt And Contract Together

Give the contract, prompt template, output schema, tool policy, model configuration, and evaluation set independent version identifiers, then record the tested combination. OpenAI’s managed prompts support versioning and template variables, but application contracts still need ownership and deployment control.

Use prompt change control for proposed revisions. Compare performance, security failures, cost, latency, and reviewer overrides on a fixed test set before promotion, and retain a known-good rollback combination.

Observe Without Leaking Data

Log contract version, variable presence, sizes, trust classes, validation rule IDs, model and prompt references, tool decisions, schema status, latency, token usage, and final disposition. Use restricted evidence storage only when an authorized investigation needs raw content.

Monitor rising rejection rates, new injection patterns, schema failures, unexpected tool denials, and reviewer disagreement. Metrics should trigger investigation, not automatic relaxation of controls.

Release With Clear Ownership

Publish contract documentation for callers, reviewers, security owners, and operators. State compatibility guarantees, deprecation dates, escalation routes, and emergency disable controls. Run a small canary before broad traffic.

The Prompt Engineering course can strengthen the reasoning behind variables, examples, constraints, and evaluations. Production reliability still depends on application validation, narrow permissions, monitoring, and accountable review.

FAQ

Is a prompt input contract just a prompt template?

No. The template is one component. The contract also defines types, trust, validation, confidentiality, tools, output schema, failures, tests, and version compatibility.

Do delimiters prevent prompt injection?

No. They clarify structure, but authorization, tool limits, validation, least privilege, output checks, and human approval must be enforced outside prompt prose.

Does a strict output schema guarantee a correct answer?

No. It constrains structure. Claims, evidence, business rules, permissions, and safety still require independent validation.