In Wonder - The World of Splectrum > Engineering > Personas > Public Conscious Persona > 1.0

Splectrum — Public Conscious Persona 1.0

This page describes how the blog operates as Splectrum’s public conscious persona. The concept is introduced in The Blog as Public Conscious Persona — this page holds the technical detail.

The model

Persona — a communication channel, a language game with its own vocabulary, rules, participants. The blog owns the conversation with its readers.
Conscious — material is made visible from other work. From that moment, the blog has full autonomy over it.
Public — the conscious mind’s work is private. The result is public. The persona speaks.

Pipeline

Full pipeline flow diagram

submissions/        — raw material arrives here, uncategorised
                      (surfaced from other repos via Mycelium)
        ↓
    intake          — evaluate, accept or reject
        ↓
drafts/             — accepted, categorised, being worked on
  core/             — substantial Splectrum, building from P1-P5
  research/         — analysing other vocabularies, from Splectrum's position
  thinking/         — small bites, specific insights, mixed
  engineering/      — practical, tools, methods, Splectrum's practice
  commentary/       — reactions, timely, open
        ↓
    production      — structure, write, edit, image, links (collaborative)
        ↓
    scheduling      — compose the blog storyline (autonomous)
        ↓
published/          — date-prefixed, pushed to Blogger

Category	What it is	Voice
Core	Substantial Splectrum. Building from P1-P5.	Splectrum speaking
Research	Analysing other vocabularies/traditions.	Observing from Splectrum’s position
Thinking	Small bites. A specific insight, question, connection.	Mix — Splectrum or external or both
Engineering	Practical. How we work, tools, methods.	Splectrum’s practice
Commentary	Reactions to current events, things encountered.	Open, responsive

Draft lifecycle

Submission — raw material in submissions/. No post standards required.
Intake — accept or reject. If accepted, categorise.
Categorised — moved to drafts/<category>/. Post storyline laid out.
Draft — full text written, edited, image, links.
Review ready — reviewed, cleaned, ready for scheduling.
Scheduled — published to published/ with date prefix. Pushed to Blogger.

Source of truth

On scheduling, the draft produces its outputs and is then deleted from drafts/. The published file becomes the master.

published/ is the master for posts
docs/ is the master for reference pages (GitHub Pages)
docs/vocabulary.md is the master for terms
drafts/ only ever contains active work — posts being prepared for scheduling

To update a live post: edit in published/, push to Blogger.

The draft file serves as the workspace during production — containing notes, post prose, page content, tasks, diagram code. On scheduling, it produces: post, reference page(s), vocabulary updates, images. Then it’s done.

Draft frontmatter

---
title: Post title
category: core | research | thinking | engineering | commentary
topic: e.g. ethics, language, Russell, workflow
status: storyline | draft | review-ready | scheduled
---

Scheduling strategy

Baseline

At least one core post per month. That’s the only rigid requirement.

Horizon

Scheduling horizon expands with productivity:

1 post/month → 1 month ahead
2 posts/month → 2 months ahead
4 posts/month → 4 months ahead
6-8 posts/month → 4-6 months ahead

Preferred dates

1st, 16th — core slots (priority)
8th, 24th — other category slots
4th, 12th, 20th, 28th — overflow when productive

Composition

Variety vs depth — alternate categories for variety, or cluster the same topic across categories for a deep dive
Flavour balance — not too many heavy core posts in a row. Engineering posts spaced out. Thinking posts as breathers.
Topical bunching — related posts close together when they build on each other
Gap scheduling — place a post where it makes sense given its neighbours

Strategic reserve

Core posts are the reserve. When material is plentiful, hold core posts back rather than scheduling immediately. This guarantees the minimum rhythm (1 core/month) even if other sources slow down. Aim: 6-12 months of core posts available in the pipeline at steady state.

Content structure

The persona publishes through three channels:

Posts (Blogger) — the conversation. Individual explorations in chronological order. The blog feed.
Anchor pages (Blogger, max 20) — sidebar navigation. Compact overviews linking to reference pages. Updated with each post publication.
Reference pages (GitHub Pages, unlimited) — the body of work. Specs, technical detail, territory summaries. Versioned. Discoverable through posts and anchor pages, opening in new tab.

Posts are moments. Reference pages are where the thinking accumulates. Anchor pages are the navigation between them.

Each post publication may trigger: anchor page update (synopsis when scheduled, full text with links when live), reference page creation or update, search engine indexing.

Scheduling checklist

Render any Mermaid diagrams to images → published/images/ (named with post date prefix)
Upload images to hosting, get URLs
Create clean post file (prose + image refs only, no notes) → published/ with date prefix
Create reference page(s) if any → docs/ with versioned folder structure
Update anchor page(s) on Blogger if needed
Schedule post on Blogger (from published file, not draft)
Add image references to post and page with hosted URLs
Update draft frontmatter status to “scheduled”
Flag tasks from draft in scheduled tasks file
Commit and push
Verify: test all image URLs are accessible, check post and page(s) render correctly on Blogger

Automation roadmap

Role	Current	Target
Submission	Manual	Mycelium — seamless cross-repo referencing
Intake	Collaborative	Autonomous AI
Production	Collaborative	Stays collaborative — we think and write together
Scheduling	Collaborative	Autonomous AI

(This page grows as the persona evolves.)