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

# Outlets & Organizations

> Model newsroom and outlet authority without collapsing organizational permissions into wallet roles.

# Outlets and organizations

PressChain distinguishes an individual cryptographic actor from the organization under which journalism is published. That distinction is necessary for real newsroom workflows, where an author can contribute to more than one outlet and an outlet can have multiple authorized people.

Capsule records carry an `outletId` alongside the author and content commitments. Canonical metadata also includes an outlet identity reference. Applications should preserve both the wallet actor and the publication context.

## Why outlet context matters

Consider a reporter who publishes independently and also writes for a newsroom. The same wallet can sign both actions, but the provenance is different. One Capsule should not inherit the organizational authority of the other simply because the author address matches.

A product should answer:

* who signed or authored the record
* which outlet identity the Capsule references
* whether that outlet relationship was valid for the action
* which contributors were attached to the individual Capsule

## Do not turn outlet membership into a protocol role

Protocol roles such as Journalist and Editor are not a substitute for organization membership. An Editor role does not make an account editor of every outlet.

Keep organization authority in the outlet or project domain where it is defined. This makes it possible to revoke access at one newsroom without changing the person’s broader protocol identity.

## Application model

A practical application model keeps these concepts separate:

```ts theme={null}
type PublicationContext = {
  actor: `0x${string}`;
  protocolRole: "Reader" | "Author" | "Journalist" | "Editor" | "Validator";
  outletId: `0x${string}` | null;
  outletPermission: "none" | "contributor" | "publisher" | "admin";
};
```

The exact outlet permission source should come from the authoritative outlet implementation, not a client-generated label.

## RSS registration example

The V3 action policy classifies RSS feed registration as an elevated economic action requiring an Editor role plus outlet administration or Enterprise project authority. That is a good illustration of layered authorization: protocol role, economic requirement and organization relationship all matter.

Delegated RSS publishing is separately modeled as a non-public delegated economic action. The design intent is non-custodial authorization, not a general server signer that can publish for every outlet.

## Rendering attribution

When showing a Capsule, prefer explicit attribution such as:

```text theme={null}
Author:  Jane Reporter
Outlet:  City Desk
Signed by: 0x8c...21f
```

rather than collapsing all three into “Owner.” Journalism often has shared, assigned or institutional provenance that cannot be represented accurately by ownership vocabulary.

## Revocation and historical records

A later permission change should not rewrite history. If an author was authorized by an outlet when a Capsule was published and is removed later, the application should preserve the original event context while applying the new permission state to future actions.

This is another reason to index transaction and block coordinates along with current organization state.

## Enterprise as platform authority

Enterprise is a platform-level role rather than protocol role ID `5`. Keep that boundary intact in APIs and interfaces. If enterprise project authority is needed for a workflow, model it as a separate permission dimension rather than mutating the canonical protocol role table.