Validation

PromptPress Documentation

Back

PromptPress validation is a post-output quality system. It checks generated results after the model responds, then records, advises, or blocks based on configuration.

The 4 Validation Layers

1. Output Contract Validation

This is always on in the worker.

It checks whether a step output matches the expected runtime shape. It is not configured from Guard Rails.

2. Guard Rail Validators

These are reusable validators attached to a workflow step in Studio.

They run after that step produces output and can be:

  • advisory
  • blocking

Use these for repeatable workflow-step policy checks.

3. Prompt Validators

Prompt validators use the same validator engine, but they are attached to a prompt version instead of a workflow step.

That means:

  • if a prompt version has validators attached
  • every use of that prompt version will run those checks automatically

Important:

  • they are not separate prompts
  • they are not inserted into a campaign
  • they are not pre-request prompt guards
  • they validate the output after generation

4. Dedicated validate Step

This is a separate workflow step type that runs the validator agent.

Use it when you need:

  • freeform natural-language criteria
  • a true LLM judge step
  • a deliberate gate between one step and the next

The validator agent always expects the machine envelope to stay valid JSON. JSON property names remain English (pass, score, failures, notes) and booleans/nulls remain standard JSON values even when the article, site language, or validation notes are Nepali or another non-English language. Human-readable failure reasons can be written in the target language inside string values.

Advisory vs Blocking

Advisory

Advisory validation records issues but does not stop the run.

Use it when:

  • you want feedback for editors
  • you are still tuning a workflow
  • the issue should not stop publication flow automatically

Blocking

Blocking validation can stop the step or run when required checks fail.

Use it when:

  • output format must be exact
  • policy failures are unacceptable
  • downstream steps should not continue on bad output

What Reusable Validators Can Do

The reusable validator system is typed and deterministic. It does not interpret arbitrary JSON keys or freeform instructions.

Current validator families include:

  • content_rules
  • json_schema
  • format
  • tone
  • sentiment
  • fact
  • citation
  • backend support also exists for persona

Best Way To Choose the Right Validation Tool

Use:

  • Guard Rails for workflow-step quality controls
  • Prompt Validators for prompt-version-wide default checks
  • Validate Step for freeform LLM judgment

Good examples:

  • Require exact JSON shape: Guard Rail or prompt validator
  • Require trusted citation domains: Guard Rail or prompt validator
  • Check whether an article truly supports a nuanced editorial claim: validate step
  • Check persona alignment heuristically: persona validator or publish persona summary

How Validation Influences Later Steps

Validators do not directly rewrite the same prompt call that just ran.

Instead:

  1. step produces output
  2. validation runs
  3. result is stored
  4. later steps can consume validation feedback

This is why validation is best understood as a gate and feedback layer, not a pre-generation steering layer.

If a validate step fails because an editor needs to correct the artifact, use the manual review flow. After the fixed content is saved, the workflow can continue on the original run from the corrected boundary step. This keeps the plan, research, draft, validation, persona, and publish steps together in one run when only the candidate output needed human repair.

Research planning and validation both include tolerant JSON parsing fallbacks. These fallbacks are safety nets for malformed model output; they do not change the contract that prompts should ask for one valid JSON object with no markdown wrapper or extra prose.

Common Misunderstandings

  • Prompt validators are not separate prompts.
  • Prompt validators do not run before the LLM call.
  • Guard Rails are not the same thing as the dedicated validate step.
  • Arbitrary config keys do not work unless the runtime supports them.

Recommended First Production Setup

For a strong but simple setup:

  1. Add one blocking JSON/format validator where output shape matters.
  2. Add one advisory tone or citation validator where editorial quality matters.
  3. Add a validate step only for the most important judgment-heavy checkpoints.

Related Docs