content-pipeline · diff
git:20260715.f00df98 to git:20260723.6e5370b
51 added, 25 removed. Audit A to A.
---
name: content-pipeline
- description: Research a topic, draft the content, and package the approved publication bundle.
+ description: Turn governed source evidence into a citation-bound reader-facing draft, channel package, and provider-neutral publication handoff.
runx:
category: content
---
# Content Pipeline
- This is the standard publish lane for runx-authored public content.
+ This is the standard preparation lane for researched content. It keeps evidence,
+ writing, packaging, and external delivery distinct so an operator can inspect
+ one concrete artifact and no local success is mistaken for publication.
- It keeps evidence collection, drafting, and publication packaging as separate
- steps so the operator can approve one concrete draft before anything is turned
- into a publish packet.
+ Use it for articles, updates, newsletters, explainers, and other channel-bound
+ content whose substantive claims need traceable support. The result should do
+ something for the reader—clarify a decision, explain a change, establish trust,
+ or enable a concrete next step—not merely prove that research happened.
- The research packet must support every substantive public claim. Draft in the
- declared channel's vocabulary for its actual readers; do not turn the graph
- trace into generic thought leadership. A useful result should change something
- for the reader—understanding, a decision, trust, adoption, or a concrete
- follow-up. Return `needs_more_evidence`, `needs_review`, or
- `not_worth_publishing` when the topic is stale, duplicative, weakly supported,
- or true but not useful.
+ ## How the chain works
- ## Output
+ 1. The caller provides the objective, audience, channel, and governed source
+ packets. Usually those packets come from `web-fetch` or a provider reader.
+ 2. `research` admits the sources, verifies citations, and decides whether the
+ evidence supports a useful deliverable.
+ 3. `ghostwrite` drafts only from the admitted claims and digests, applying any
+ supplied voice or operator context without treating it as factual evidence.
+ 4. The validated draft is packaged deterministically for the declared channel.
+ 5. A provider-neutral handoff records the target and approval requirement. The
+ lane stops before external delivery.
- - `research_packet`: bounded sources, verified claims, inference, and gaps.
- - `draft_content`: the reader-facing artifact grounded in that packet.
- - `approval_decision`: the operator's decision on the exact draft.
- - `publish_packet`: approved content and channel metadata, never an implicit publish.
+ Local research, drafting, and packaging require no approval. A later provider
+ skill owns the consequential gate, idempotency, send or publish request,
+ acknowledgement, and readback.
- ## Inputs
+ ## Inputs and result
- - `objective` (required): what the content should accomplish.
- - `audience` (optional): intended reader or operator segment.
- - `channel` (optional): publication channel; defaults to `blog`.
- - `domain` (optional): ecosystem or market area to research.
- - `operator_context` (optional): constraints, voice, or campaign context.
- - `target_entities` (optional): structured list of products, projects, or
- actors the research pass should keep in view.
+ - `objective` states what the content should change for its reader.
+ - `source_packets` contain bounded governed evidence.
+ - `audience`, `channel`, and `domain` shape the artifact.
+ - `operator_context` and `target_entities` narrow interpretation but are not
+ source evidence.
+ - `publication_target`, `boundary_kind`, and `approval_context` prepare the next
+ lane; they do not authorize it.
+
+ The result preserves the citation-validated research packet, the evidence-bound
+ draft, a deterministic channel package with `not_sent` state, and a
+ provider-neutral handoff. `needs_more_evidence`, `needs_review`, and
+ `not_worth_publishing` are valid terminal states when the topic is unsupported,
+ stale, duplicative, or unhelpful.
+
+ ## Stop conditions
+
+ - Stop before drafting when the source packet is missing or invalid.
+ - Do not turn operator context, campaign intent, or a target URL into evidence.
+ - Withhold any draft whose material claim cannot be tied to an admitted digest.
+ - Do not add delivery or publication evidence to a local package.
+ - Route the exact accepted artifact into the relevant provider lane instead of
+ rebuilding it there.
+
+ ## Example
+
+ An operator wants a blog post explaining a new governance boundary. The lane
+ can validate official docs and receipt evidence, draft for engineering readers,
+ package the accepted body for the blog, and prepare a CMS handoff. It cannot say
+ the post is live until an approved CMS operation and provider readback prove it.