# The `pr-` convention — campaign repositories

A `pr-` repository is a **campaign**: an ongoing public-communication offering
with its own voice, cadence, consent records and budget. It consumes one or more
`fluid-*` interfaces and owns none of them.

This document exists so the second campaign repository does not have to be
reverse-engineered from the first. `pr-hall-of-helix` is the first instance.

## Why the prefix says `pr-`

The prefix covers public relations, promotion, **and propaganda** — including the
uncomfortable third word deliberately. A campaign repository that cannot name
what it is doing will not govern it well.

The distinction between the three is not the mechanism, which is identical in all
cases. It is whether the campaign is accountable to something outside itself: a
source document it must not contradict, a named reviewer, a consent basis it can
lose. Everything in this convention exists to keep that accountability
structural rather than cultural, because culture does not survive a deadline.

## What makes a repository a campaign

Three properties, together. A repository with only one or two of them is
something else.

1. **It speaks outward, in an organisation's voice**, to an audience that did not
   ask to be written to.
2. **It writes about people** — usually people who did not commission the writing.
3. **It does not finish.** A campaign has a cadence, not a completion criterion.
   This is why campaigns must not live inside a workplan: a workplan that never
   finishes is a workplan that has stopped being honest.

## Required contents

### `INTENT.md`

The ordinary repository intent, plus the campaign's own three questions
answered explicitly:

- **Audience** — who is being written to, and what they did to deserve the
  attention (usually nothing; they are strangers, and that is the point).
- **Voice** — how the organisation sounds here, and why that is appropriate.
- **What it will not say.** The most important of the three and the one most
  often skipped. A campaign with no stated refusals has not decided anything; it
  has merely not yet been tempted.

### Consent records

For every person the campaign writes about: the basis, its date, and how it may
be revoked.

Three rules that are not the campaign's to relax:

- **Absence of objection is not consent.** Silence is not agreement, and treating
  it as such is the single most common failure in this class of work.
- **A standing agreement does not apply retroactively.** People whose
  contributions predate the agreement are asked, not assumed in.
- **Revocation is honoured going forward**, and the record says so before anyone
  needs it.

### Composition strategies as named variants

Every composed artifact records the `variant` label of the strategy that produced
it, at composition time.

Not afterwards. Reconstructing which strategy wrote what from timestamps is the
kind of inference that works until it quietly stops, and by then the comparison
it feeds has already been believed.

### A publishing cadence

Stated, and slow enough to review at. A backlog is a source to draw on, not a
queue to drain — publishing it in a burst is a rate-limit problem, an unkind
introduction for a new subscriber, and a volume of writing nobody has had time to
read properly.

### A review step

A person reads each artifact against its source before it goes out, and their
name travels with it.

This is not ceremony. A condensation can put a claim in someone's mouth that
their own source never made, and **in an audit trail an unfaithful artifact looks
exactly like a faithful one.** No downstream check recovers this, because there
is nothing anomalous to detect. The reviewer is the only mechanism that works.

## The boundary against `fluid-*`

| Campaign (`pr-`) owns | Interface (`fluid-*`) owns |
|---|---|
| Composition and the editorial voice | The contract and its revisions |
| Choosing what is worth publishing | The adapter: rendering and delivery |
| Variant strategies and their competition | Delivery experiments |
| Consent records and the review queue | Per-variant engagement reporting |
| The publishing cadence | Platform and channel configuration |
| The *declared* presence (names, descriptions, assets) | *Applying* that declaration, and custody of every credential |

A campaign reaches its interface through the published contract and nothing else.
It does not import the adapter, read the evidence store, or hold a credential.

The separation is architectural rather than stylistic: composition is a
probabilistic editorial task, and `ArchitectureBlueprint.md` §48.1 forbids an LLM
in the mandatory request path. Putting composition in the campaign is what keeps
the interface deterministic.

### Presence lives with the campaign

A bot's name, its description, and the channel titles a stranger reads are
**brand, not mechanism**, so the declaration belongs to the campaign. The
interface holds the schema, applies the declaration, and owns the credentials
that result. See `fluid-telegram/docs/provisioning.md` for the worked case.

## Registration

- Repository name: `pr-<campaign-slug>`
- State Hub domain: **the domain of the subject being promoted**, not a domain
  named for marketing. The domains are market sectors, and a campaign is
  classified by what it is about. `pr-hall-of-helix` is `infotech` because
  HelixForge is.
- Topic: the subject's topic, so a query for that subject's work returns the
  campaign with it (`pr-hall-of-helix` → `helix-forge`).
- Workplan prefix: derived from the repo slug (`PRHOH-WP-`).

## Its own FLUID loop

A campaign is a consumer of an interface, and it may also run its own FLUID loop
over its own artifacts — which composition variant travels — using the
per-variant engagement the interface reports.

These are different loops over different questions and should not be merged. The
interface's loop asks *how should this be delivered*; the campaign's asks *what
should be said*. The first is settled by the platform's constraints; the second
never fully settles.

## The test of this convention

Whether a second campaign can be created from this document without reading
`pr-hall-of-helix`. Until that has happened, treat the convention as a
description of one case rather than a general rule — see `FLUID-WP-0009` T05,
which makes the same point about the framework itself.