My AI Practice Needed a Publishing Pipeline. So It Built One.
When a governed system produces more content than you can publish manually, the missing layer is operations.
Two weeks into publishing with my governed AI practice, the content problem inverted. Creation was no longer the constraint — I had forty scheduled Substack Notes, social blurbs across five platforms, cross-workspace drafts pulled from case studies and essays. All of it living in markdown files the system had already produced. What I didn’t have was a way to see it, copy it, or track what I’d posted.
The first case study showed the system could build quickly. The second showed that sessions compound instead of resetting. This one tests something harder: whether the system can build the operational tooling required to publish its own output.
The schedule lived in a markdown table — forty rows, five columns, source codes like L6A and CS2-D3 pointing to draft files in different directories. The blurbs lived in separate files across three workspaces. The cross-workspace Notes — ideas that emerged from one project but belonged to the publishing calendar — lived in yet another file. Every morning I was opening four or five documents to figure out what to post next.
So the same practice that produced the content built the tooling to publish it. One session. Same dashboard, same parser architecture, same constraint: the Content Queue is a lens, not a repository. It reads from the files the system already uses and writes only minimal state. If the tool disappears, the content is still there.
The Mapping Problem
The hard part wasn’t the interface. It was the resolution layer — connecting source codes to actual content across a file structure that had grown organically.
L6A meant launch sequence Note 6A inside a drafts file with ### Note 6A headers. CS2-D3 meant the third derivative Note from Case Study #2, under ## Note 3 headers in a different directory. E2-D1 meant Essay 2’s first derivative. XW-1 meant cross-workspace Note 1, in yet another file with its own format. Promo entries had no body at all — the label in the schedule table was the content.
Five source patterns. Four file locations. Three heading conventions. The parser had to resolve all of them to produce a single content queue with copy-to-clipboard buttons and word counts.
This is the kind of problem that would have required a schema migration in a traditional content management system. Here, it required reading the files the way they already existed. No reformatting. No import step. The parser learned the structure the content had already chosen for itself.
Persistence followed the same logic. Scheduled Notes already had a home — the markdown table tracked their status. But blurbs and cross-workspace Notes had no write-back target. The answer was a lightweight JSON file alongside the dashboard. Scheduled Notes write back to both. Everything else writes to the JSON file only. Two persistence paths, zero migration.
Content Before Containers
While building the Content Queue, I was also writing Notes to post that day. One of them was a cross-workspace piece I’d drafted earlier in the week:
Here’s a design rule I keep returning to: content before containers. Don’t build the filing system before you know what you’re filing. Don’t create the workspace before you have work. Don’t organize until organization earns its overhead.
I posted that Note to Substack using the Content Queue — clicked Copy, switched to the browser, pasted, published, switched back, clicked Mark Posted. The tool tracked it. The JSON file recorded the timestamp. The Posted tab showed it alongside the scheduled Notes from the same day.
A Note about not building structure before content, posted using a tool built after the content existed. The principle and the proof arrived in the same session.
The dashboard wasn’t built before the workspaces needed it. The Content Queue wasn’t built before the publishing pipeline needed it. The system doesn’t plan tooling. It waits until the work forces the need.
The Honest Part
The Content Queue only discovers content from files that follow conventions the parser knows. If a new workspace produces publishable content in a format the parser hasn’t seen, it won’t appear. The system is as structured as its inputs — and right now, those inputs are manually maintained markdown files. If the file conventions drift, the parser drifts with them.
The conventions the parser relies on exist because a single operator maintains them. A multi-operator system would require stricter schema enforcement — something closer to a content management system, which is exactly what this approach is designed to avoid.
There's a related constraint I haven't tested yet: what happens when the content isn't all produced by the same AI. This pipeline assumes one tool, one set of conventions, one file structure. A system that spans multiple AI tools — each with its own session memory, its own style of output — would need the governance layer to hold what no single tool can see.
There are no automated tests for the parser. It proves correctness by successfully resolving real content during publishing sessions. That’s a feature of the workflow when the builder is also the publisher. It’s a risk when they aren’t.
And the 55-item content queue sounds impressive until you consider that each of those items was written in previous sessions, scheduled in previous sessions, and organized into files in previous sessions. The Content Queue didn’t create any content. It surfaced content the system had already produced. The invisible labor is everything that came before.
What This Is Actually About
The first case study proved the system builds fast. The second proved it compounds across sessions. This one proves something different: the system can manage its own output.
A governed AI practice that produces content, tracks that content in structured files, and then builds its own publishing operations layer from those same files — that’s not a productivity trick. That’s operational infrastructure. The content pipeline didn’t need a product manager. It needed the same methodology that built everything else.
The Content Queue took one session because the architecture was already there. The constraint was already there. The content was already there. The only thing missing was the lens.
Case Study Insight: A governed AI practice that builds its own publishing operations from its own structured files isn't just productive — it's operationally self-sustaining.
Robert Ford builds products, writes stories and essays, and publishes The Intelligence Engine — a Substack about building AI practices that compound. His other writing lives at Brittle Views.