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

# Reviews & Challenges

> Build review and challenge interfaces around explicit role, bond and economic policy.

# Reviews and challenges

PressChain treats review and challenge activity as explicit protocol actions rather than informal UI reactions. The V3 action policy specifies who can participate, which economic class applies and which additional state requirements must be satisfied.

## Reviews

`review.submit` is defined for Journalist, Editor and Validator roles. It requires an active bond and uses the micro fee class.

A product should not present a review submission as a generic “like” button. The action represents a role-bound protocol contribution.

Before authorization, the interface can show:

* connected PressKey identity
* active role
* bond status
* Capsule being reviewed
* economic class and current network amount
* content or evidence the review references

## Challenges

`challenge.open` is a public economic action requiring identity, an active bond and the elevated fee class.

That increased economic friction reflects the fact that opening a formal challenge can create downstream protocol work and should not be equivalent to a costless comment.

## Application flow

```mermaid theme={null}
flowchart LR
  A[Select Capsule] --> S[Load current state]
  S --> E[Check role and bond]
  E --> R[Resolve action rule]
  R --> P[Prepare challenge or review]
  P --> K[Authorize with PressKey]
  K --> T[Track transaction]
  T --> I[Refresh indexed state]
```

## Do not put policy in the button

Avoid code such as:

```ts theme={null}
if (role === "Validator") charge("3 PRESS");
```

The role and fee class are protocol semantics, while the amount can be network policy. Resolve them through the active authority configuration so testnet changes or approved mainnet economics do not require hunting through UI components.

## Challenges need evidence context

A challenge interface should encourage structured references rather than a bare accusation. Link the challenge to the relevant Capsule, claim, evidence item or revision where the active protocol model permits it.

The application can also offer a dispute evidence path so a challenger can preserve the artifact supporting the challenge.

## Surface unresolved state

A challenge should remain visible while unresolved. One of the automatic bounty trigger categories is unresolved challenge, reflecting the protocol’s interest in routing attention toward open verification work.

Do not hide unresolved items merely because they make a Capsule page visually messy. They are part of the record’s current verification context.

## Product tone

Challenge UX should be procedural rather than adversarial. Good labels describe state: “Challenge opened,” “Evidence requested,” “Under review,” “Resolved.” Avoid copy that declares fraud or guilt based solely on the existence of a challenge.

Protocol transparency works best when the interface separates allegation, evidence, review and final state.