Proposals and Editor Override

A proposal is a change to a publication written down where readers can see it: a story draft, a new concept, a rename, a merge, a split. The rule is short: AI proposes, readers steer, editors decide.

This is built and tested. Shipped, our open-code demonstration site, shows the queue with example drafts. Readers' votes work once a site turns on reader sign-in, which is done one site at a time.

The queue

Every proposal carries its state in words and with a mark, never by colour alone: Draft, In steering, Editor review, Approved, Declined, or Overridden by editor. Each shows who proposed it (AI), what evidence backs it, how many signed-in readers voted up or down, and the draft itself to read. A reader can also flag "This is wrong" or suggest a better name. Votes rank the queue and advise editors.

The usual source of story drafts is Cited Trends. Other proposals come from the knowledge run, for example a cluster that should be renamed or two that should be merged.

Editor Override

Editors have a tier of their own. All of it is for people in the editor and admin groups:

• Approve or decline a proposal.
• Pin it to float it, or hold it so that nothing moves it until released.
• Override the community: decide against the readers' view, with a public reason. The community result is fixed when review starts and stays visible beside the editor's.
• Set aside votes under a fixed rule, for example votes from accounts under 24 hours old. The page says how many were set aside and why, and the editor can restore them.
• Needs a look: the snapshot flags proposals an editor should look at, such as unusual voting. Those flags are for staff and are never public.

Who acted is never in a public file. No file holds an email address or a reader's internal identifier.

The details are in the Papyrus repository, in docs/reader-steering.md.