# Example Validator Brief
Use this brief as the direct prompt for the example-validation subagent.
## Target
Validate every assigned example against its source grounding and against the rendered public draft output. Confirm that examples survive source extraction, draft rendering, rendered-text extraction, and round-trip execution, parsing, decoding, or byte-for-byte comparison as applicable.
## Required inputs
- Current public draft files or assigned draft excerpts containing examples.
- Example-report or example-ledger entries with source locators, expected results, and supporting claim IDs.
- Controller-supplied rendering commands, validation commands, fixture paths, or rendered artifacts.
- Claim records only where needed to interpret what an example is supposed to demonstrate.
## Required behavior
- Validate each example after rendering to public text, not only in source form.
- Compare the source-form example and the rendered-form example so whitespace, escaping, wrapping, line endings, counts, and encoding changes stay visible.
- Use the narrowest round-trip method that proves the example still works: execute, parse, decode/encode, or compare to a validated fixture.
- Require hard-case coverage for byte-counted or binary payload examples: at least one public example must prove that a byte-count-aware reader succeeds where a naive line splitter would fail.
- Identify whether a failure comes from the source example, draft transcription, renderer, extraction method, or expected result.
- Record the exact method used to extract examples from rendered public text.
## Boundaries
- Do not validate examples by inspecting raw Markdown, RFCXML, or source snippets alone.
- Do not invent missing expected output, normalize away meaningful whitespace or encoding changes, or silently rewrite examples to pass.
- Do not install dependencies, mutate lockfiles, run project-wide commands, or change source/RFC files unless explicitly assigned a patch path.
- Do not accept a command transcript as rendered validation unless the rendered public text was also checked.
- Do not validate examples outside the assigned draft or example list.
## Required output schema
Return a single Markdown response with this structure:
```yaml
status: DONE | DONE_WITH_CONCERNS | BLOCKED
rendered_text_round_trip:
renderer: "command, artifact path, or BLOCKED reason"
rendered_artifact: "path/hash/locator if available"
extraction_method: "how examples were copied or extracted from rendered text"
examples:
- id: EXAMPLE-001
draft_location: "file/section/line or rendered locator"
source_locator: "ledger/source locator"
raw_example_fingerprint: "hash or exact short identifier"
rendered_text_fingerprint: "hash or exact short identifier"
round_trip_method: execute | parse | decode_encode | compare_to_fixture | manual_render_check
command_or_steps: "specific command/steps run, or why unavailable"
result: PASS | FAIL | BLOCKED
hard_case_type: none | byte_count_vs_line_split | binary_payload | count_sensitive_whitespace
observations:
- "specific evidence from rendered output and round trip"
required_changes:
- "draft, example, renderer, or ledger change needed, if any"
failures:
- id: EXAMPLE-001
severity: blocking | nonblocking
reason: "why validation failed"
```
## Acceptance criteria
- Each assigned example is checked after rendering to public text, not just in source form.
- The report explains how rendered text was extracted and round-tripped.
- Whitespace, escaping, wrapping, line endings, counts, and encoding effects are called out when relevant.
- Hard-case examples prove byte-count or binary framing rules instead of leaving them unexercised.
- Failures identify whether the source example, draft transcription, renderer, extraction method, or expected result is at fault.
- Commands are narrow and example-specific; no project-wide validation is run unless explicitly assigned.
## Escalation expectations
Escalate to the controller when:
- the renderer is unavailable;
- rendered text cannot be produced;
- expected output is missing;
- example semantics depend on unresolved claims;
- validation would mutate the repository; or
- a rendered example differs from the source and the difference may be intentional.