> ## Documentation Index
> Fetch the complete documentation index at: https://docs.eyeparity.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Proof lifecycle

> Understand how EyeParity evidence becomes accepted current proof.

Evidence gains authority through verification and acceptance. A file existing on disk is not enough. The artifact must be attributable to the correct task, served from the expected tenant boundary, and corroborated by deterministic state.

## Lifecycle states

<Steps>
  <Step title="Capture">
    Produce the exact route and viewport needed for the task after the relevant implementation and runtime events.
  </Step>

  <Step title="Corroborate">
    Record API, DOM, OCR, pixel, status, or provenance facts that independently support the visible claim.
  </Step>

  <Step title="Annotate">
    Create a task-specific callout that identifies the exact region satisfying the acceptance criterion.
  </Step>

  <Step title="Review">
    Inspect the rendered image and compare advisory visual analysis with the deterministic facts.
  </Step>

  <Step title="Accept or supersede">
    Promote evidence only when the proof contract passes. Replace it when a newer implementation or runtime event invalidates the prior packet.
  </Step>
</Steps>

## Current versus diagnostic evidence

Diagnostic captures help investigate failures but do not close current-green claims. Historical and superseded evidence can explain how a defect evolved; it cannot prove the current product state.

<Note>
  When a server restarts, a route becomes stale, or a data-plane mismatch is detected, recapture the affected surface before accepting it as current proof.
</Note>

## Evidence hierarchy

Deterministic facts control exact state claims. Visual analysis is advisory and should be reconciled against route metadata, API responses, DOM facts, and artifact provenance. When they conflict, keep the task open and investigate the mismatch.