Validation — PAG — Bane's Lab

Validation Gates

Validation gates are checkpoints that verify conditions before proceeding. They provide structure for the AI to confirm requirements are met.

Gate Structureα

Each validation gate contains one or more check items with optional evidence and failure actions.

Gate Structure
VALIDATION GATE:
  ✅ file_exists("config.json")
  ✅ schema_valid(config, CONFIG_SCHEMA)
  ✅ dependencies_resolved

  IF FAIL:
    REPORT "Validation failed"
    EXIT 1

Check Markersβ

Marker	Meaning	Usage
`✅`	Success check	Visual verification point
`ASSERT`	Hard assertion	ASSERT condition
`REQUIRE`	Prerequisite	REQUIRE dependency
`[high]`	Priority high	Critical validation
`[medium]`	Priority medium	Standard validation
`[low]`	Priority low	Optional validation

Phase Transition Rulesγ

Gates guide phase progression. The AI should verify all gates pass before moving to the next phase.

Phase N should complete before proceeding to Phase N+1
All ✅ markers should evaluate to true
IF FAIL actions indicate what to do on gate failure
Task markers track progress: [ ] pending, [x] complete, [>] in progress

Writing Effective Conditionsδ

Gate conditions should be specific and concrete rather than vague and subjective. Specific conditions give the model clearer patterns to follow.

Quality	Example	Why
`Specific`	customer_email matches email_pattern	Concrete pattern to check
`Specific`	record_count > 0	Clear numeric comparison
`Specific`	all required_fields present	Defined existence check
`Vague`	email looks valid	Subjective interpretation
`Vague`	data is good	Undefined criteria
`Vague`	everything worked	Unclear scope

Limitations

Understanding PAG's boundaries helps set appropriate expectations for both individual documents and multi-agent orchestrations.

Known Boundariesε

PAG provides structured guidance but operates within inherent constraints of LLM-based systems:

No Runtime Execution

PAG documents are instructions, not executable code:

The LLM reads instructions and uses its available tools
PAG describes what to do, not how the LLM processes it
No guarantee the LLM will follow every instruction precisely

No Confidence Introspection

PAG cannot query model internal states:

Validation gates check outcomes, not prediction certainty
No way to say "only proceed if confidence > 90%"
Gates verify observable conditions only

Probabilistic Output

LLM outputs are inherently variable:

Same document may produce different results across invocations
PAG provides structure but cannot guarantee determinism
Critical operations should include verification steps

Context Window Constraints

Token limits affect document size:

Complex documents may need chunking or summarization
Handoff signals pass summary context, not full history
Long workflows may lose early context without preservation

Sequential Agent Execution

Agents execute one at a time:

Each agent must complete before the next begins
DAG patterns express parallelism but depend on tooling
Long orchestrations have cumulative latency

No Cross-Session State

State doesn't persist automatically:

Workflow state must be explicitly written to documents
Resumption requires reading workflow-state file
Design with checkpoint awareness

Tool Availability Dependency

PAG assumes tools are available:

EXECUTE Task requires Task tool in agent's toolset
File operations require Read, Write, Edit tools
Agent capabilities vary — PAG cannot guarantee availability

No Feedback Loops

PAG describes linear or branching flows:

Agents cannot "watch" for changes in real-time
Iteration requires explicit FOR EACH structures
WHEN blocks require tool support for event handling

αGate Structure βCheck Markers γPhase Transition Rules δWriting Effective Conditions εKnown Boundaries