Skip to main content

​
ConstraintType

Severity levels for behavioral constraints. These levels communicate different degrees of requirement to the AI model, following RFC 2119 conventions for requirement keywords.

​
Type Definition

export type ConstraintType = "must" | "must_not" | "should" | "should_not";

​
Levels

​
must
literal
Absolute requirements that cannot be violated. Use for critical security, privacy, or functional requirements.
​
must_not
literal
Absolute prohibitions that cannot be violated. Use for forbidden actions or behaviors.
​
should
literal
Strong recommendations that should be followed when possible. Use for quality standards and best practices.
​
should_not
literal
Strong recommendations to avoid, but not absolute prohibitions. Use for discouraged but not forbidden behaviors.

​
When to Use Each Level

  • must: Security requirements, data validation rules, legal compliance
  • must_not: Privacy violations, prohibited content, harmful actions
  • should: Quality standards, tone preferences, user experience guidelines
  • should_not: Anti-patterns, discouraged approaches, style preferences

​
Constraint

A behavioral constraint or guideline for the AI agent. Constraints define rules that govern the agent’s behavior and are organized by severity level in the generated prompt to communicate priority and flexibility to the model.

​
Type Definition

export type Constraint = {
  type: ConstraintType;
  rule: string;
};

​
Properties

​
type
ConstraintType
required
The severity level of this constraint. Determines how this constraint is grouped and presented in the system prompt. Higher severity (must/must_not) indicates non-negotiable requirements, while lower severity (should/should_not) indicates preferences and recommendations.
​
rule
string
required
The actual constraint rule text. Should be written as a clear, actionable guideline. Use imperative mood and be specific about the expected behavior. Avoid ambiguous language.Examples:
  • "Cite sources for all factual claims"
  • "Avoid technical jargon when explaining to beginners"

​
Usage Examples

​
Security Requirement

const constraint: Constraint = {
  type: "must",
  rule: "Always verify user authentication before accessing personal data"
};

​
Prohibition

const constraint: Constraint = {
  type: "must_not",
  rule: "Never store or log sensitive user information"
};

​
Recommendation

const constraint: Constraint = {
  type: "should",
  rule: "Provide concise responses when user seems in a hurry"
};

​
Discouraged Behavior

const constraint: Constraint = {
  type: "should_not",
  rule: "Avoid making assumptions about user's technical expertise"
};

​
Best Practices

  1. Be Specific: Write clear, actionable rules rather than vague guidance
    • Good: "Cite sources with URLs when making factual claims"
    • Bad: "Be accurate"
  2. Use Imperative Mood: Start with action verbs
    • Good: "Validate input parameters before processing"
    • Bad: "Input parameters should be validated"
  3. Choose Appropriate Severity: Match the constraint type to the requirement level
    • Critical requirements → must or must_not
    • Best practices → should or should_not
  4. Avoid Ambiguity: Be explicit about expectations
    • Good: "Respond within 3 sentences for simple queries"
    • Bad: "Keep responses short"

​
Integration with PromptSmith

import { PromptSmith } from 'promptsmith';

const prompt = new PromptSmith()
  .withIdentity("Customer Support Agent")
  .withConstraint({
    type: "must",
    rule: "Always verify user identity before discussing account details"
  })
  .withConstraint({
    type: "should",
    rule: "Maintain a friendly and professional tone in all interactions"
  })
  .withConstraint({
    type: "must_not",
    rule: "Never promise refunds without manager approval"
  });

const systemPrompt = prompt.build();

​
How Constraints Appear in Prompts

Constraints are automatically organized by severity level in the generated system prompt: 
## Constraints

### Must
- Always verify user identity before discussing account details

### Must Not
- Never promise refunds without manager approval

### Should
- Maintain a friendly and professional tone in all interactions

Build docs developers (and LLMs) love

Get started for freeTalk to us