Content Production and Marketing Pipeline — 2026

Owner: Uriel · Parent: Content publishing · Tasks: Beads lip-93f.2.16 (bd list --parent=lip-93f.2.16; all associated work: bd list --label project:2602-content-delivery-pipeline; brief and SCQ tasks lip-1ie.3, lip-kv8.5) · Analysis: LTP report

Summary

• What: a reliable, sustainable way to take recorded and written material through to published and promoted content, with an owner for each step.
• Why now: too much stays unreleased for months (2RCon, the Debold episodes, the April course videos), and what does go out gets little follow-through (Dougald Hine).
• Diagnosis: three root causes; Rufus ranked the brief first on 2026-10-20. (1) Pieces enter post-production with no brief: no decision on what they become and no captured context. (2) No release trigger: "ready" is never defined for each output. (3) No SOPs after post-production, so QC, marketing and release steps leak.
• Plan (v1): a brief at intake and one approval pack per piece; readiness standards and a release trigger per output; SOPs, starting with light-touch YouTube release; gather and triage the backlog; small AI experiments. We build the pipeline by shipping real pieces through it, not through a separate pilot.
• Now: gathering the backlog into one list (lip-93f.2.16.6). Next: the YouTube fast-release SOP and the brief interview prompt.
• Caveat: the diagnosis is Rufus's, partly backed by a read of Asana. Asana and the GitHub board are both incomplete, so no tracker is yet a source of truth.

Status

Task state lives in Beads; this table only shows the shape.

SCQ

Situation: We record and collect material: interviews, talks, dialogues between hosts, event sessions, course videos, and some writing. Most of it is video and audio. Turning it into published work means deciding what each piece becomes, producing and packaging it, releasing and promoting it, and following up.

Complication: Material does not reliably make it to a finished, well-promoted release. Much stays unreleased for months, and published pieces that do well get little further promotion. The main reason, in Rufus's diagnosis (partly backed by Asana), is that pieces enter post-production with no brief, so post-production is confused and work is redone. Two further causes and the fixes are in root causes below.

Question: How do we reliably turn new and existing material into worthwhile, published and well-promoted content—from deciding what to make of it through to follow-up—at a quality and pace we can sustain?

Goal tree

Top level only; the full tree, with its 31 necessary conditions, is in the LTP diagrams. ◀ marks where Rufus and Uriel see the bottleneck.

Goal: Life Itself reliably turns new and existing material into published,
      well-promoted content, at a quality and pace we can sustain,
      and keeps improving its production factory as it learns
├─ Ideas are generated and chosen                      (needed, not the bottleneck)
├─ Each piece gets a timely decision on what it becomes, in a brief   ◀
├─ Production and post-production are efficient
├─ Each output meets a quality standard fit for it, with QC           ◀
├─ Each piece has the marketing materials its track needs             ◀
├─ Ready pieces are released, announced and promoted                  ◀
├─ The pipeline is written down, followed, partly automated and owned
└─ We track how pieces perform and learn from it

Root causes and fixes

Conflicts and how we resolve them

Causes 2 and 3 are not ranked against each other. From the seven evaporating clouds in the LTP; resolutions are Rufus's.

The pipeline

Stages from the process map (draft, under review). The map and its workflow diagrams are meant to become SOP and handbook material that people and AI can follow.

1 Development → 2 Pre-production → 3 Production → 4 Post-production ─┬→ 5 Packaging → 6 Review and release → 7 Promotion
                                                     triage gate 4.1 ─┴→ hold / abandon
8 Follow-up and learning (monthly): promote → 5 · lessons → SOPs and skills · referrals → 1
0 Operations, across every stage

The brief (root cause 1) is written in development or at the triage gate, before substantial post-production. The release trigger (root cause 2) sits in stage 6. The SOPs (root cause 3) cover stages 5 to 8 first.

Agreed by Rufus on 2026-09-25: for Seeds of Renaissance audio and video, the host triages each piece onto a track before substantial post-production, defaulting to fast release; pieces that do well are promoted later. See publication tracks, which still need revising to the one-brand naming (.16.5).

Issue tree

Answers added on 2026-10-20 come from the LTP session with Rufus and Uriel.

• What brief must the pipeline deliver against?
  • Where do decisions about audience, purpose, editorial offer, and channel priorities belong? ✅ In the linked content strategy project; this project turns that direction into a workable delivery process.
  • Is this primarily a rebranding-launch pipeline? ✅ No — it concerns ongoing publishing; launch communications remain a distinct project.
  • Must pipeline improvement wait for the full content strategy? ✅ No — substantial operational work can proceed using current releases and provisional case briefs, while strategy develops in parallel.
  • Which brands, streams, and channels should the first improvement cover, and what strategic brief is sufficient to guide it? ✅ Partly: SOPs start with light-touch YouTube (fast release) for Seeds of Renaissance, then the newsletter, white papers and the magazine (Rufus, 2026-10-20). What strategic brief is sufficient remains open.
  • When and by whom should the intended use of material be decided or revisited, including material whose value emerges after recording? ✅ For SoR audio/video: the host triages before substantial post-production, defaulting to fast release; well-performing fast releases can be promoted later (publication tracks).
  • What must the brief establish about the main output, its destination, supporting material, and initial release versus follow-up? ✅ For SoR audio/video: which track (episode or fast release), which sets the default destination and minimum packaging, with fuller packaging deferred to the promote step (publication tracks). It also captures the context the team needs: how we know the guest, the promotion plan, structure, timing, titles and branding (Rufus, 2026-10-20).
• What currently prevents finished, well-promoted releases?
  • Where do real pieces wait: deciding their use, editing, producing ancillary material, review, or distribution—and why? Current hypothesis (Rufus, 2026-10-20, partly backed by Asana): at the missing brief before post-production, at approvals requested one by one, and at the hand-off to social; plus a backlog of recorded episodes. Not verified piece by piece.
  • For the April course, is the unresolved question only whether to release? ✅ No — Rufus reports that the larger question is how, including an announcement, landing page, and other ancillary material; whether to release also remains open.
  • What prevents further promotion when a published piece shows promising audience response? ✅ There is no follow-up step or promote trigger; the tracks propose a monthly look at performance (Rufus, 2026-10-20).
  • How do capacity, ownership, unclear quality standards, and missing material or context contribute to waiting and rework? Current hypothesis (LTP current reality tree, 2026-10-20; candidate causes, not verified): unstated quality levels and missing context caused constant confusion in post-production; no one owned the pipeline until October; one producer carries most steps.
• What changes would improve delivery within our capacity?
  • What minimum workflow, responsibilities, handoffs, and reusable defaults would take a piece from selection through follow-up?
  • What quality standards and release criteria protect the audience experience without making every possible improvement a prerequisite?
  • Which evidenced constraints need changes in decisions, people, or process, and which justify DAM, AI assistance, or integration? ✅ Partly, for AI: use it by output type (templates, drafted words, checked facts), tested in small experiments (LTP AI cloud, 2026-10-20). DAM remains open; in September it had not been shown to be the highest-value intervention.
  • What bounded trial would demonstrate better completed releases and follow-through, at sustainable effort and quality? ✅ No separate pilot: build the pipeline by shipping real releases through it; the earlier pilot chain was closed (Rufus, 2026-10-20).

Scope

Ongoing publishing, separate from the rebrand launch. The content strategy project decides what we publish, for whom and why; this project decides how we deliver it, including marketing as real production work and reuse of existing material. The two run in parallel (Rufus, 2026-09-23): strategy is not a prerequisite, and choices that depend on it (programme identity, channel architecture, a new public destination) are made locally or deferred.

Key documents

• LTP report, diagrams and ltp.yaml — the full reasoning: goal, current reality, conflicts, future reality, prerequisites.
• Publication tracks — the SoR episode / fast release / promote procedure.
• Content production process map — stages and activities; draft, the basis for SOPs.
• AI fit map — where AI helps, from the Asana read; to be redone on top of the process map.
• Initial case evidence — 2RCon and Emergent Dialog, from GitHub, 23 Sept.
• Background — earlier framing, reported examples, the original pipeline drawing and its analysis, and sources.
• Publications SOP — sub-project for written publications.