Communications use cases

Moved here from life-itself/comms ref/comms-use-cases.md on 2026-10-09, to keep the what and why with the Comms Infrastructure project. The product and channel inventory stays in the comms repo. To be consolidated with the CRM motivation and job stories later.

This is the upstream record of the real communications jobs across Life Itself and related projects. The technical use cases and requirements derived from these needs live in the crm repo, ref/email-infrastructure.md — that document is the "how it's built" counterpart to this "what we need and why."

Verified means checked against the live site and/or its local repository on 2026-08-02. TBC means the detail needs confirmation.

Distillation of the current state

• Communications are spread across several independent brands, domains, site repositories, Substacks, Luma registrations, the custom devspaces-mailer, Brevo, and Twenty CRM.
• Four active or intended publications currently use Substack: Life Itself, Developmental Spaces, Seeds of a Second Renaissance, and Life Itself Research. AI, Learned Today has a fifth Substack but is not being sent regularly.
• Developmental Spaces is the closest thing to a reusable flow: its site form and three email courses use devspaces-mailer, and newsletter signup is tagged in Twenty. Synchronizing those subscriber records onwards to Substack is still a manual, one-way CSV process; this is separate from publishing newsletter content.
• Second Renaissance course and event registration is fragmented across Luma pages. Life Itself also uses ad hoc event/course capture rather than a standard project pattern.
• Open Revolution still has legacy Brevo/Sendinblue forms and sequences whose operational status is unclear.
• Some projects have no capture at all; others link or embed Substack directly. There is no consistent organization-wide signup pattern.
• The largest practical publishing failure is Substack's lack of a supported write/send API. AI can tidy a link or comment, accumulate several short items, and assemble a weekly or fortnightly post, but somebody must still log into Substack and operate its interface. That final manual step means posts often do not get sent, notably for AI, Learned Today and some Developmental Spaces/Teal Estate updates.
• Subscriber, consent, preference, and suppression state is fragmented across providers and Twenty. There is no single clearly documented authoritative state or reliable synchronization model.

Cross-project needs

Concrete communication stories

These stories expose two distinct automation jobs: provisioning and subscriber flow, and content preparation and publishing. Solving only one leaves the main friction in place.

First vertical slice: AI, Learned Today

MVP story

capture links, notes, and newly published site material
→ retain source, comment, date, and status in an item backlog
→ AI deduplicates, checks links, and assembles a Markdown issue
→ publish or preview the canonical issue on ailearnedtoday.com
→ create the exact email draft and audience programmatically
→ human reviews the rendered issue and recipient summary
→ one approval action schedules or sends it
→ delivery and suppression events reconcile automatically

Programmatic publishing does not mean ungated publishing. It means the reviewer does not have to log into a provider to copy content, fix formatting or images, enter metadata, choose an audience, or perform routine configuration. Approval may happen in a small Life Itself interface, a pull request, or another fast review surface.

Product acceptance criteria

• Zero content copy/paste or routine configuration in the provider dashboard.
• One idempotent command/prompt creates or updates the site issue, email draft, preview, audience summary, and proposed schedule.
• Review shows the exact content, images, links, sender, subject, recipient count, and schedule; approval takes under two minutes.
• Approval records approver, time, content hash, audience snapshot, and schedule. Any subsequent content or audience change invalidates it.
• Repeating preparation, approval, or a timed-out send does not create a duplicate issue or broadcast.
• Unsubscribes, hard bounces, and complaints prevent the next eligible send and reconcile to the chosen authoritative state.
• Existing Substack archives remain reachable during migration; only eligible subscribers are imported and the old signup is replaced deliberately.

Decisions still needed before implementation

1. Where the lightweight item backlog lives and how a link/comment is captured into it.
2. Whether every digest becomes a permanent public page on ailearnedtoday.com (recommended) or email only.
3. Which approval surface is fastest on desktop and mobile.
4. Cadence, minimum item count, maximum issue size, and what happens when there is insufficient material.
5. Whether open/click analytics are wanted or disabled for privacy.
6. Could Twenty be authoritative for whether someone may be emailed, at least for simple signup and unsubscribe forms? Compare this explicitly with making the email provider or a dedicated Life Itself ledger authoritative; do not assume the answer yet.

Project summary

Verified course and event surfaces

Derivation into email infrastructure

The recurring requirement is not primarily "give us a newsletter editor." It is a reusable, AI-operable provisioning and distribution path:

one prompt naming a site and purpose
→ branded signup form
→ audience/list or course configuration
→ consent and suppression tracking
→ CRM tagging/synchronization
→ deploy and verify
→ optionally generate a digest from site content and create/send a newsletter

These communications needs produce the editorial-broadcast, operational-message, transactional, and lifecycle-sequence categories evaluated in the crm repo's ref/email-infrastructure.md. Substack remains a real incumbent and possible publishing destination, but the absence of a supported write/send API creates a required UI step that is already preventing newsletters from being sent. Replacing it remains in scope; Buttondown should not be preferred merely because it is another managed newsletter product. The eventual comparison should test which system best supports the reusable flows above.

Appendix A: product/use-case map

This is the compact map that connects each product to its current channels and the jobs we need those channels to support. The detailed account list lives in product-channel-inventory.md.

This appendix is about product context and jobs. It does not decide which provider owns sending, subscriber eligibility, or membership.

Separate future research: paid membership and subscriptions

Paid membership is a separate problem and must not determine the current email-infrastructure conclusion without its own research.

• Second Renaissance currently earns approximately 1,000 per year from paid subscribers to Seeds of a Second Renaissance and pays approximately 100 per year through Substack's 10% platform fee. Currency remains TBC.
• Future research should cover membership records, entitlements, payments, renewals, failed payments, tax/VAT, member-only content/community access, exports, migration, and the boundary between a newsletter subscriber, paid supporter, and organizational member.

Still to confirm

1. The currency for Second Renaissance paid-subscription revenue.
2. Whether Life Itself's homepage email form successfully subscribes or only opens the Substack page.
3. Whether AI, Learned Today's embedded signup is visible and working in a normal browser.
4. The current status of the Open Revolution Brevo sequence and where its contacts should live.
5. Whether Life Itself Research will become Second Renaissance Research and whether its current Substack should move or merge.
6. Any additional sites/projects omitted from the spoken list.

Related records

• Technical implementation, provider evaluation, and runbooks: crm repo, ref/email-infrastructure.md