> ## 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.

# Community & Official Evidence

> Understand the two evidence participation paths and the different authority each path represents.

# Community and official evidence

PressChain distinguishes broad participation from canonical publication authority. That distinction makes it possible to let readers contribute useful evidence without granting every connected identity the ability to rewrite the publisher’s official source set.

## Community evidence

The V3 action policy permits an authenticated PressKey identity to participate in the community evidence path without requiring an active publishing bond. The action is classified as a micro-fee economic action and remains subject to validation, duplicate controls, quota limits and abuse enforcement.

This is useful for applications that want readers, researchers or witnesses to surface material relevant to an existing Capsule.

A product can present this as “Submit evidence” while clearly identifying that the evidence came from a community participant.

## Official evidence

Official evidence is restricted. Under the V3 policy it is intended for Author, Journalist or Editor roles with an active bond, and authority depends on a valid relationship such as Capsule author, approved contributor, outlet authority or protocol administration.

At the current V3 contract layer, canonical `addEvidence` explicitly authorizes the Capsule author, an attached contributor or contract admin.

The difference matters. Official evidence appears as material intentionally attached to the canonical publication context. It should not be confused with an external submission simply because both ultimately reference a URI and hash.

## Dispute evidence

`submitDisputeEvidence` gives the contract a distinct challenge path. It reserves evidence type `255`, sets the label to `DISPUTE_EVIDENCE` and records the submitting address.

An application can make this visible with a dedicated “Disputes” section rather than mixing it into the official evidence list.

## Suggested interface model

```ts theme={null}
type EvidenceRelationship =
  | "official"
  | "community"
  | "dispute";

type EvidenceCard = {
  relationship: EvidenceRelationship;
  submittedBy: string;
  label: string;
  uri: string;
  contentHash: string;
  active: boolean;
  finalized: boolean;
};
```

The relationship should be derived from the protocol path and policy, not from a client-side checkbox supplied by the submitter.

## Preflight official attachment

Before showing an official attachment transaction, check the Capsule relationship:

```ts theme={null}
const capsule = await capsuleCore.getCapsule(capsuleId);
const isAuthor = capsule.author.toLowerCase() === account.toLowerCase();
const isContributor = await contributorRegistry.isCapsuleContributor(capsuleId, account);

if (!isAuthor && !isContributor) {
  throw new Error("This PressKey identity cannot attach canonical evidence to the Capsule");
}
```

Administration is an operational path and should not be represented as a normal end-user permission.

## Label provenance in the UI

The point of multiple participation paths is lost if the UI renders every item identically. Show who submitted the evidence and what relationship the protocol recognizes.

Useful labels include:

* Official evidence
* Community submission
* Dispute evidence

Those labels describe provenance. They are not a substitute for reading the evidence itself.

## Abuse resistance without silencing contribution

Community participation should remain bounded by quotas, duplicate prevention and economic friction. Those mechanisms protect the evidence graph from spam without requiring the protocol to make every community participant a bonded publisher.

Applications should surface rate or quota errors accurately rather than retrying around them.