Complete content pipeline architecture for AI Execution Lab — workflow definitions for every content type, review checklists, publication QA, and weekly/monthly cadence.
This document defines the publishing operations system for AI Execution Lab. It covers pipeline architecture, per-content-type workflows, the review and QA process, and the operational cadence that produces consistent output.
All content passes through five stages regardless of type:
TRIGGER → DRAFT → REVIEW → PUBLISH → MAINTAIN
| Stage | What Happens | Who / What Does It |
|---|---|---|
| Trigger | Something happens that warrants documentation | Real work session, failure, experiment, system decision |
| Draft | Content created from the event | Claude-assisted or manual, using the relevant template |
| Review | Accuracy, completeness, GEO checklist | Human operator — 15–30 min depending on type |
| Publish | Frontmatter set, status: published, file committed | git add → commit → push |
| Maintain | Periodic freshness check, internal link updates | Quarterly audit via content queue system |
The pipeline is pull-based, not push-based. Content is triggered by real work, not by a publishing schedule that demands content whether or not something happened. The cadence goal is velocity with substance — not volume for its own sake.
Trigger condition: Any significant work session — deployment, automation run, content batch, architecture decision, configuration change.
Minimum bar for logging: If you made a decision you'll need to remember later, or completed a task that took more than 30 minutes, it's worth logging.
Workflow:
content/_templates/execution-log.mdxcontent/logs/YYYY-MM-DD-[short-slug].mdxstatus: "published", commit, pushCadence target: 2–3 logs per week during active work periods. Zero is acceptable during no-work weeks — do not invent logs.
GEO priority: Medium. Logs accumulate into a temporal record that shows active, ongoing work — valuable for entity credibility. Individual log GEO value is low; aggregate value is high.
Trigger condition: Anything that broke in production, took more than one attempt to fix, cost significant time, or has a non-obvious root cause that others would benefit from.
Minimum bar for reporting: If you'd want to find this information in a search result before hitting the problem yourself — publish it.
Workflow:
content/_templates/failure-report.mdxcontent/failures/[descriptive-slug].mdxstatus: "published", failure_status: "resolved" (if resolved), commit, pushCadence target: Publish every failure. Even small ones. A failure archive with 50 entries is a significant authority asset that compound-grows for years.
GEO priority: Highest. Failure reports with exact error messages are the highest-value GEO content on this platform. When a developer searches an exact error message, a failure report that matches it exactly gets cited by AI search systems at high rates. These are the "long tail with zero competition" entries.
Trigger condition: A topic exists in a track module that has been researched and can be taught to the skill level of that module's audience.
Minimum bar for publishing: Content is accurate, specific enough to execute from, and follows the track's difficulty level. Not "good enough" — complete.
Workflow:
content/_templates/lesson.mdxcontent/lessons/[track-id]/[module-id]/[lesson-id].mdxlib/tracks.ts: change lesson status from 'coming-soon' to 'available'status: "published" in frontmatter (tracks.ts drives lesson availability)Cadence target: 1–2 lessons per week for active modules. No lesson per week is acceptable — force no output by a publishing schedule.
GEO priority: High for specific how-to lessons. Lessons that teach a named skill with named tools rank for those specific tool + skill queries.
Trigger condition: A repeatable procedure has been executed at least twice and proven reliable. Not theoretical — the playbook documents something that works.
Minimum bar for publishing: The procedure has been tested in production. Every step is specific enough that someone could follow it without asking questions.
Workflow:
content/_templates/playbook.mdxcontent/playbooks/[descriptive-slug].mdxCadence target: When a procedure earns it. Not scheduled. Rushing a playbook to hit a publishing target produces untrustworthy documentation.
GEO priority: Highest for well-named, specific procedures. Playbooks with exact procedure names ("WordPress REST API content patching system") match specific queries at high precision.
Trigger condition: An architectural decision, infrastructure design, or operational system has reached a stable form worth documenting.
Minimum bar for publishing: The system is live and has operated successfully. Not a planned system — a real one.
Workflow:
content/_templates/system-doc.mdxcontent/systems/[descriptive-slug].mdxCadence target: Low — perhaps quarterly when a system stabilizes. Do not manufacture system docs for velocity.
Trigger condition: A project or experiment has measurable before/after results that demonstrate a specific technique's effectiveness.
Minimum bar for publishing: Real numbers. Real before/after. No estimated or projected outcomes — measured ones.
Workflow:
content/_templates/case-study.mdxcontent/case-studies/[descriptive-slug].mdxCadence target: Quarterly, as results materialize. One real case study outweighs ten articles.
Trigger condition: An experiment was run with a hypothesis, methodology, and observable outcome.
Minimum bar: The experiment had a defined hypothesis before execution, was run with some form of controlled conditions, and produced observable data.
Workflow: Same as case study, using content/_templates/geo-experiment.mdx for GEO-specific experiments.
Run this on every piece of content before setting status: "published":
<h1> (title)## heading answers that heading directlytitle is specific, matches contentdescription is 100–160 characters, contains primary topicdate is accuratetags cover the primary topics (3–6 tags)status: "published" (not draft)After publishing (after git push and Vercel deploy completes):
Minimum viable cadence for consistent growth:
| Day | Activity | Output |
|---|---|---|
| Monday | Review backlog, assign this week's content | 3–4 items selected from queue |
| Tuesday | Write deep content (failure, system, playbook) | 1 piece |
| Wednesday | Write lesson or doc content | 1 piece |
| Thursday | Write execution log(s) for work done | 1–2 logs |
| Friday | QA pass, publish all drafted content, update internal links | All pieces live |
Minimum output: 3 pieces/week. Achievable in 4–6 hours total. Target output: 5 pieces/week during active build phases. Acceptable exception: 1–2 weeks per quarter with zero publishing during intensive work phases.
Focus: Execution logs + failure archive growth
Why: Logs and failures are the lowest-friction, highest-aggregate-value content. Establishing cadence is more important than polishing individual pieces.
Focus: Playbooks + systems documentation
Why: Playbooks and systems content is highly specific and highly citable. This phase builds the "reference-grade documentation" reputation that GEO authority requires.
Focus: Case studies + measurable outcomes
Why: Case studies are the highest-authority signal — they show results, not just processes. At 6+ months, results from early work are starting to materialize.
At this point the platform has: 100+ execution logs, 30+ failure reports, 10+ playbooks, 5+ case studies, and 3+ complete track modules. Authority compounds automatically — new content gets indexed faster, existing content ranks higher, AI systems cite the platform consistently.
Focus shifts to: Deeper content, more experiments, guest contributions from the ecosystem, content-to-product pipeline (where Lab content generates leads for A Square Solutions services and TrustSeal/ScamCheck products).