Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/xxyoudeadpunkxx/pa-pvp-mini/llms.txt

Use this file to discover all available pages before exploring further.

pa_pvp mini produces structured findings with machine-readable provenance metadata. Every field in a finding is required, and every claim made in that finding must be anchored to observable content inside ORIGINAL_ARTIFACT. The format is designed to be readable by both humans and automated tools — and to be directly challengeable in the next round. A finding that cannot be checked against the artifact is not a valid finding.

​
Finding Anatomy

Each finding is written as a compact header line followed by three named sub-fields. Here is the full structure: 
- [finding_id] [fix_id] [origin_round] [derived_from] [severity] [label]
- what_breaks: [one concise statement]
- evidence: [observable reason anchored to ORIGINAL_ARTIFACT]
- fix: [structural change required]
Each field in the header line carries a specific meaning: finding_id A single keyword drawn from the problem itself. The ID names the structural issue being identified. Use a word that uniquely identifies the problem: padding, merge-conflict, sev-boundary, gate-missing, rollback. No numbers. No category prefixes. The ID must be specific enough that a reviewer in Round 3 can look at it and know exactly which problem it refers to. fix_id Same keyword convention as finding_id, but names the fix rather than the problem. It identifies what changes. The fix_id travels forward through rounds — it appears in the Merge Status block to indicate which fixes are confirmed, challenged, or new. origin_round The round number where this finding first appeared. In Round 1, every finding has origin_round: 1. In Round 2+, confirmed or challenged findings carry their original round number forward. New findings found for the first time in Round 2 carry origin_round: 2. derived_from The finding_id of a previous finding that the current finding replaces or evolves from. Use NONE when the finding stands independently with no lineage. Use a prior finding_id only when this finding directly supersedes, refines, or extends a specific prior finding — not merely when it is related to the same area. Severity Three levels:
LabelMeaning
HIGHBreaks core function, correctness, execution viability, or downstream trust
MEDWeakens reliability, robustness, auditability, or prioritization without core collapse
LOWReal structural weakness with limited blast radius
When severity is ambiguous between two levels, the reviewer must choose the lower level and explain why in the finding. Label Indicates the provenance of the finding this round:
LabelMeaning
INDEPENDENTReached by the current reviewer before consulting any prior output
CONFIRMEDPrior finding that the current independent review also supports
CHALLENGEDPrior finding that the current review disputes
NEWProblem not present in prior output, identified for the first time
what_breaks One concise statement of the failure. Describes the structural consequence: what goes wrong, what fails to execute, what produces incorrect output, or what creates downstream breakage. evidence An observable reason anchored directly to ORIGINAL_ARTIFACT. The evidence must be specific — naming the step, rule, condition, or structural element in the artifact that produces the problem. General claims without artifact anchoring are not valid evidence. fix The structural change required to resolve the finding. The fix must change something real in the artifact. See Finding Validity Rules for what qualifies.

​
Provenance Rules

Finding IDs are the continuity mechanism across rounds. They allow a finding to be tracked, confirmed, or challenged over multiple passes without ambiguity.
  • IDs are reused across rounds for the same problem. If Round 1 identified a finding with finding_id: gate-missing and Round 2 independently finds the same issue, it must use the same ID — not a new one. The PREVIOUS_ROUND_OUTPUT is the reference for existing IDs.
  • New IDs are never assigned to already-tracked problems. Reassigning a different keyword to a problem that already has an ID breaks provenance tracking and makes the Merge Status unreliable.
  • derived_from tracks evolution, not similarity. Use it only when a finding directly replaces or refines a specific prior one. If Round 2 identifies a more precise version of a Round 1 finding — for example, narrowing the scope of the problem or replacing the fix — the Round 2 finding uses the same finding_id and puts the Round 1 finding_id in derived_from. If two findings are related but neither replaces the other, derived_from is NONE for both.
The section concentration rule caps findings per section: no more than two findings may target the same section of the artifact. If one section contains concentrated structural failure, the reviewer may report up to four findings on that section, but must mark the output with SECTION OVERLOAD JUSTIFIED to explain the exception. This prevents a single noisy section from consuming the entire finding budget and obscuring problems elsewhere.

​
Finding Validity Rules

A finding is only valid if all five of the following conditions are met:
  1. Observable. The problem can be seen in the artifact. It is not inferred from intention, guessed from context, or derived from what the artifact “should” do.
  2. Specific. The finding points to a particular step, rule, element, or condition — not a general area or a category of concern.
  3. Actionable. There is a concrete fix. A valid finding always has a valid fix. A finding with no valid fix must be excluded.
  4. Structurally relevant. The problem affects how the artifact functions, not how it reads. Style, tone, and wording are not structural unless they create ambiguity that changes behavior.
  5. Anchored to ORIGINAL_ARTIFACT. Every claim — in the finding, in the evidence, and in the fix — must be traceable to content in the artifact.
What makes a fix valid? A fix must change at least one of the following:
  • structure
  • behavior
  • constraints
  • decision rules
  • flow
  • validation
  • operational clarity
Pure wording changes are invalid as fixes unless they remove ambiguity that directly changes how the artifact is executed or interpreted. A fix that only makes the artifact read more clearly, without changing what it does, is not a structural fix.

​
Example Finding

The following is a complete valid finding in pa_pvp mini format: 
FINDINGS:
- validation fix-validation 1 NONE HIGH INDEPENDENT
- what_breaks: Input is passed to the database before validation can reject it
- evidence: Step 2 (Save to database) follows Step 1 (Validate input) with no conditional gate between them
- fix: Add a conditional branch after Step 1 that halts execution on validation failure before Step 2 runs
Breaking this down:
  • validation — the finding_id, drawn from the structural problem (missing validation gate)
  • fix-validation — the fix_id, naming the fix
  • 1 — this finding originated in Round 1
  • NONE — it does not derive from a prior finding
  • HIGH — a missing validation gate before a database write is a core correctness failure
  • INDEPENDENT — reached before consulting any prior output
  • what_breaks — states the failure in one sentence
  • evidence — names Step 1 and Step 2 from the artifact and observes the missing gate
  • fix — describes the structural change: a conditional branch that halts execution on failure
For the full output format specification, including the Merge Status block and the END OF PROTOCOL marker, see Output Format.

Build docs developers (and LLMs) love

Get started for freeTalk to us