Prompt pipelines need ownership

A production prompt is one stage in a pipeline, not a private note:

user input
  -> context builder
  -> prompt template
  -> model call
  -> parser
  -> checks
  -> product action

A regression can enter at any stage. The template may be fine while retrieval changes, the parser hides malformed output, or a model upgrade shifts behavior under the same prompt.

Every prompt needs an owner who reviews changes, maintains fixtures, watches failures, and decides when the prompt is obsolete. Without ownership, prompt behavior becomes folklore: one patch adds policy, another changes the schema, and nobody can explain the combined result.

Fixtures should cover real failures: long inputs, missing fields, hostile phrasing, stale retrieval, low-quality documents, partial tool output, and edge cases near the schema boundary. If a prompt change fixes a production failure, keep that case.

Use deterministic checks first. Parse the output, validate required fields and enums, check citations, and reject forbidden fields before spending judge-model or human review time on meaning.

Version the prompt, examples, model, and output contract. Keep a rollback path. That is how a prompt stays a maintained dependency instead of becoming a hidden production assumption.