Deployment Environments

Software systems have development, staging, and production environments. Prompt systems need the same separation. This is not bureaucracy — it is the architecture that makes it possible to change a production prompt without affecting users while the change is being validated, and to validate the change against realistic inputs before it reaches users.

Development environment: the prompt is being authored and iterated. Inputs are synthetic or sampled. The model may differ from production (a faster, cheaper model for iteration speed). No production traffic. No production data. The only rule is that changes made here do not affect users.

Staging environment: the prompt has passed unit tests and is being validated against realistic inputs. The model matches production. Input data mirrors production distribution (using anonymized or sampled production logs, not synthetic data). Traffic is internal — QA, the owning team, integration testing. This is where integration issues surface: the prompt works in isolation but breaks when called from the actual application with the actual data pipeline.

Production environment: real users, real inputs, real consequences. Prompts here have passed both unit testing (golden dataset) and staging validation. Changes to production prompts require a promotion workflow with documented sign-off.

# Environment-specific prompt configuration
# Each environment specifies the prompt version and model variant
# The application resolves prompt content at startup from this config

environments:
  development:
    prompt_source: "local"          # Load from local prompt files
    model: "kimi-k2-5-turbo"        # Faster, cheaper for iteration
    temperature: 0.7
    logging: "verbose"
    rate_limit: null
    feature_flags:
      new_output_schema: true       # Dev always tests new features

  staging:
    prompt_source: "library:draft"  # Load from library, draft status permitted
    model: "kimi-k2-5"              # Production model
    temperature: 0.2
    logging: "full"
    rate_limit: 1000                # per hour
    feature_flags:
      new_output_schema: true       # Staging tests the same flags as prod-next

  production:
    prompt_source: "library:active" # Only active (approved) prompts
    model: "kimi-k2-5"
    temperature: 0.2
    logging: "structured"
    rate_limit: 50000               # per hour
    feature_flags:
      new_output_schema: false      # Not yet rolled out to production

# Prompt version pinning per environment
prompts:
  sales-email-007:
    development: "latest"          # Always latest in dev
    staging: "2.3.0"               # Pinned pending validation
    production: "2.2.1"            # Stable, approved version

  ops-summarize-001:
    development: "latest"
    staging: "2.1.0"
    production: "2.1.0"            # Staging and production aligned