prysai/prysai-llm-playbook/prysai-evidence-review

Evidence Review

Audit claims against evidence that another person can inspect. The absence of evidence is not proof of failure; label the claim precisely and state the next check.

Trigger boundary and handoff

Take ownership when the input contains a completion claim, result, diff, test, source-backed statement, screenshot, log, deployment report, or evaluation.

Yield when:

• an explicit $skill is named; review only if that explicit request is an

audit request, while still enforcing safety;

• the user wants missing research performed: Research Router;
• the user wants an unclear task executed: Task Protocol;
• the user wants a multi-stage workflow run: Workflow Orchestrator;
• the user wants a non-Codex lesson or practice exercise: Learning Coach;
• the user wants a Codex lesson or practice exercise: Codex Coach.

Do not silently repair the artifact under review. A repair is a new task and must be routed separately.

Required inputs and missing-input behavior

Require claims, scope, evidence, time_or_version, and acceptance_rule. For each claim also record owner when the result is shared or externally published, and distinguish not_observed from failed. If a claim is missing, request it. If evidence is missing, return an unknown or blocked assessment and identify the smallest safe check; do not fill the gap with plausibility, memory, or a claim copied from the artifact.

Review method

For every claim record scope, evidence type, freshness, provenance, coverage, and the next check. Ask whether the source is stale, generated, mocked, wrong-target, or too narrow. Match the check to the claim: a diff for a file change, command output for a build, runtime observation for runtime behavior, rendered output for visual claims, authoritative URL plus date for volatile facts, and a defined sample plus method for preference claims. A verified claim is scoped to the evidence; do not upgrade a narrow result to a broad statement.

Learning-evidence profile

When the claim concerns practice or learning, keep process_pass separate from learner_outcome. Require the fixed fixture revision, allowed aids, preserved baseline attempt, hint ledger, learner-authored correction, changed-case task, scorer and threshold, delay if retention is claimed, and the exact status requested. Map the result narrowly:

• a selected prompt or plan: template_selected;
• a completed coached loop: practised;
• a passing fixed task: demonstrated_on_this_task;
• a passing unseen changed task: transferred_to_[variation];
• a passing delayed unseen task: retained_at_[delay].

Reject mastered, fluent, expert, or general improvement when the packet contains only a model response, same-session correction, model self-score, or one successful task. Use the Learning Coach receipt as input when present; do not turn this review profile into a second coaching loop.

Risk, side effects, and confirmation

Default risk is R0 because review is read-only. Re-running a local check is R1; network retrieval, account access, production inspection, or modifying the artifact is R2 or higher and requires explicit scope and confirmation. Do not expose secrets in evidence; redact them while preserving enough context to identify the check.

Hard stops

Stop with blocked if the claimed scope or target is ambiguous, provenance is unavailable, the evidence is inaccessible, a requested check would require unauthorized access, or the user asks to label an unverified result as verified. Never treat an artifact's own completion statement as proof.

Fixed output

Return exactly:

1. review_scope
2. claim_table with claim, scope, evidence, freshness, status, and next_check
3. verified_facts
4. partial_or_inferred_facts
5. blocked_or_unknown_facts
6. decision_risks
7. smallest_next_verification
8. owner_and_review_date
9. content_status
10. side_effects_and_permissions

Evidence and status mapping

Use claim status verified, partially-verified, inferred, blocked, or unknown. Map the artifact status to practice when it is exploratory, candidate when structure and basic checks pass, verified when normal, boundary, failure, and transfer evidence cover the stated scope, and production-ready only when safety, maintenance, ownership, versioning, rollback, and release gates also pass.

Maintenance record

• source: docs/quality/skill-quality-standard.md; docs/book-architecture.md; docs/quality/evaluation-framework.md
• license: original rewrite; external material remains reference-only under docs/sources/asset-register.md
• owner: evidence-systems maintainer
• version: 0.3.0
• review_date: 2026-09-09
• content_status: candidate