Evidence and claims are the operating core of CITAQ, because public verification only works when assertions stay tied to inspectable support.

This hub gathers the routes that explain how CITAQ models evidence, separates stronger and weaker support, governs claim lifecycle, and represents expiry or revocation when the public trust surface changes.

The architecture source treats these as real system layers. Evidence levels, evidence-bound claims, proof objects, expiry, and revocation are not side notes. They define whether the public route graph remains defensible.

Use This Page
Use this route to move through the evidence-governance side of the public platform.

It is for readers who need to understand how claim support is modeled, how status changes over time, and how trust output stays connected to underlying proof.

The evidence and claim layers this hub should connect

Evidence Levels

Evidence levels explain why different support sources should not be treated as equal in public verification.

Evidence-Bound Claims

Claims only become durable public assertions when they can point to inspectable supporting artifacts or records.

Claim Lifecycle

Claims need rules for creation, change, downgrade, retirement, and public-state transition over time.

Proof Objects

Proof objects are the concrete evidence-bearing references that keep verification pages from collapsing into vague promise language.

Evidence Expiry

Time-sensitive support needs explicit recency handling so stale artifacts do not silently keep live claims afloat.

Revocation and Status

A credible public trust system must show changed and withdrawn states, not only positive ones.

Open the main evidence and claim pages

Use the adjacent docs, resources, and trust pages

Evidence and claims should stay connected to adjacent clusters

Trust routes depend on evidence behavior

Public interpretation breaks down when trust pages do not explain the support model, expiry behavior, and status logic underneath them.

Standards routes strengthen the proof layer

Credentials, DID, GS1, C2PA, and status lists matter here because they can shape how evidence and status become more machine-readable.

Method routes explain how public outputs are produced

Verification model, evidence model, hash integrity, and badge semantics need their own connected public hub so method discovery is not trapped inside leaf pages.

Directory routes make the graph easier to browse

Large public systems need indexing surfaces so evidence topics remain connected to docs, resources, standards, and verification pages.

Open the standards hub if you want the machine-readable proof layer next.

Evidence and claims define the support model, while standards routes explain how identity, credentials, provenance, and revocation strengthen public verification.