Release

In plain words: Broadcast: publishing and corrections

Designed 1 min read 2 glossary terms 6 connected pages
The short version written for the Snayu team

How Broadcast publishes a candidate to an external destination as a separate approved effect, and later issues corrections or takedowns.

Why read it: Read before building any publish, correction or takedown integration.
  1. 1Draft and public publishing are distinct effects with idempotency keys and receipts.
  2. 2A lost acknowledgement leaves remote state unknown; browser automation cannot retry it.
  3. 3Corrections and takedowns keep the original publication history.

Words on this page, decoded click one for its card

The original text Underlined words open their plain-English card.

The candidate can remain local forever and still be finished. Release begins when the editor chooses to put those exact bytes before an external audience, with a destination and an attributable approval.

Review before effect

Source support, claims, voice/likeness authority, privacy/PortalCloud Model use, accessibility, asset admission, and render checks supply their own receipts. Publication additionally binds candidate digest, destination, audience, visibility, schedule, disclosures, cost, and approving Principal.

broadcast.publish_draft@2 and broadcast.publish_public@2 are distinct effects over PublicationCandidate@2. Each pins idempotency key, payload/request digests, destination identity, reconciliation lookup, and PublicationReceipt@1. A lost acknowledgement leaves unknown remote state until inspection resolves it. Browser automation supplies no authority for an untyped retry.

After release, a correction or removal must still be attributable to the publication it changes. broadcast.correct_publication@2 creates a forward correction. broadcast.takedown@2 requests removal while preserving the publication and receipt history. If a platform refuses, authority expires, the candidate changes, remote state remains uncertain, or a gate fails, return that exact blocker.

Recovery begins by resolving the pinned PatternWorkflow, source, handoff, script, timeline, renderer, adapter, and receipt revisions. Their retention needs differ: snapshots, rejected renders, candidates, destination receipts, and analytics retain separate policies. Deletion therefore inventories derivatives, requests authorized remote removal, and preserves a content-free receipt. Feeds and caches may still retain copies.

Proving package

Before testing an external release, prove its local candidate. Build a three-to-five-minute piece from frozen sources: linked claims, article/script, local narration with back-transcript, admitted visual/music/language/picture-sound bundles, captions, explicit timeline, deterministic render, bounded repair, EditorialPackage@2, and PublicationCandidate@2. The fixture makes no platform call.

Return to Broadcast, or inspect the local candidate in Render.