The Publish Loop: Knowledge → Article → Post → New
Node
The Publish
Loop: Knowledge → Article → Post → New Node
Introduction: The
Engine That Feeds Itself
Engine That Feeds Itself
Every knowledge system has a dirty secret: most of them produce
content once and then stop. The knowledge sits in the vault, the blog
sits on the site, and the two never talk again. Articles get published,
then orphaned. The vault accumulates facts, but the public site doesn’t
reflect them. The gap between internal knowledge and external content
widens until the system is just two separate piles pretending to be
integrated.
The self-improving knowledge base solves this with a publish loop — a
closed cycle where internal knowledge becomes published authority, and
published authority generates new internal knowledge. Not a pipeline
that runs once. A loop that runs every time something is worth
saying.
This article is a walkthrough of that loop: how knowledge in the
Council Vault becomes an article, how that article becomes a live
WordPress post, and how that post feeds back into the vault as a new
node. The loop is the engine’s circulatory system. Understanding it is
the difference between a wiki and a content operation.
Phase 1: Knowledge Seeding
(The Vault)
(The Vault)
The loop begins inside the Council Vault — the internal knowledge
graph that stores everything the system knows. The vault is organized by
schema, not by folders: entities (things), concepts (ideas), and sources
(evidence). Every node has a template, every template has mandatory
fields, and every field links to something else.
Knowledge enters the vault through three channels:
- Imported sources — notes, logs, documents, research
papers. Each becomes a source page with structured metadata and verbatim
claims. - Generated entities and concepts — the wiki pipeline
writes new pages against entity and concept templates, grounding each
claim in source links. - Agent session transcripts — Hermes memory layers
capture what agents discussed, decided, and learned. These become vault
material, not throwaway logs.
The vault is not a filing cabinet. It is a living graph where every
node has inbound links, outbound links, and provenance. The linting
system (covered in S3.3) ensures that orphans, dead links, and
ungrounded quotes are caught mechanically — not noticed by a human three
months later.
When the vault reaches a density threshold — enough nodes on a topic,
enough cross-references, enough source grounding — the system flags a
publishable seed. This is the input to Phase 2.
Phase 2: Article Drafting
(Pipeline)
(Pipeline)
The publish pipeline takes a vault seed and expands it into a full
article. The pipeline lives in 04-Pipeline/ and follows a
deterministic process:
Seed selection. The CONTENT-ROADMAP-99 defines 99
article slots across 10 series, each grounded in specific wiki concepts
and skills. A seed is selected based on series position, vault density,
and coherence with previously published articles. S3.7 (this article)
was seeded from the publish loop itself — the system writing about its
own process.
Outline against templates. The article follows a
structural template: frontmatter (tags, grounding, wiki concepts,
skills), introduction with problem statement, body sections that
reference wiki nodes, and a conclusion that connects back to the series
arc. Every wiki reference uses the [[wiki-link]] format,
and every factual claim traces to a source.
Draft generation. The article is written as a
markdown file with YAML frontmatter. The frontmatter is machine-readable
— it lists wiki concepts, skills, tags, and grounding nodes that
downstream tools use for indexing, search, and bridge updates. The body
is human-readable — prose that explains the system to an audience that
doesn’t know the internals.
Provenance tracking. Every article gets a companion
JSON file (ARTICLE-S3-7-provenance.json) that records the
image generation prompt, model, cost, vault paths, and tags. Provenance
is the audit trail — it answers “where did this come from?” without
requiring a human to remember.
Phase 3: Publishing
(WordPress)
(WordPress)
The article moves from vault to live site through the
lucidhive-wp-publish skill. The publish process is not a
click — it is a structured operation with verification at every
step:
-
Container discovery. WordPress runs in Docker
Swarm. The container name changes on redeploy, so the publish script
discovers it dynamically viadocker ps --format. No
hardcoded names. -
HTML creation. The markdown article is converted
to HTML and copied into the container. Thewp post create
command takes title, status, category, and tags. The status is always
publish— drafts are for unfinished work, not for the
production pipeline. -
Duplicate guard. Before creating, the system
checks for an existing post with the same title. A crashed or retried
worker might have already published. The guard queries the database
directly and skips if a match exists — no duplicates, no orphan
posts. -
Category and tag assignment. Categories and tags
are verified after creation. WordPress’s tag/category name collision
(where “Digital Architecture” exists as both a category and a tag)
requires direct database verification. The publish script runs
wp post term listand fixes any misassignment. -
Featured image. The hero image (generated in
Phase 2 or sourced from the media inventory) is imported via
wp media importand linked to the post via
_thumbnail_id. The image gets a title and alt text for
accessibility and SEO.
The output is a live post on lucidhive.com with a real URL, real
tags, and a real featured image. Not a draft. Not a staging preview.
Published.
Phase 4: The Feedback Loop
(New Node)
(New Node)
This is where the loop closes. A published post is not the end of the
process — it is input to the next cycle.
MASTER-INDEX-BRIDGE update. The bridge document
(07-Daily/lucidhive.com/posts-map/MASTER-INDEX-BRIDGE.md)
maps every published post back to its vault sources. After publishing,
the bridge is updated with the new post ID, title, and wiki connections.
The post count increments (249 → 250), and the bridge’s taxonomy
analysis is refreshed.
IDEAS-BACKLOG update. The backlog
(04-Pipeline/IDEAS-BACKLOG.md) tracks every idea from seed
to published. After publishing, the backlog entry is updated with the
post ID and status change from “developing” to “published — post XXXXX.”
This is the audit trail for content operations.
New wiki node. The published post itself becomes a
source node in the vault. It is imported as a source page with the post
URL, publication date, and content summary. This source page then
grounds future entity and concept pages — creating a reference that
other articles can cite.
Media inventory update. The hero image is cataloged
in the media inventory (JSONL format) with model, cost, tags, and vault
paths. Orphan images from the inventory can be paired with future
articles, reducing generation costs.
The loop is now complete: knowledge → article → post → new node →
knowledge. The vault is denser, the site is richer, and the next article
has more material to draw from.
Why the
Loop Matters More Than Any Individual Article
Loop Matters More Than Any Individual Article
The publish loop is not about any single article. It is about the
compound effect. Every article makes the next one cheaper to write (more
vault material), faster to publish (more automation), and more
trustworthy (more cross-references). The system gets measurably better
with each cycle.
The 249 published posts on lucidhive.com are not 249 isolated pieces
of content. They are 249 nodes in a knowledge graph that feeds itself.
The loop is the reason the graph stays alive — not a static archive, but
a growing, self-referencing system where every publication creates the
conditions for the next one.
This is what separates a knowledge OS from a blog. A blog publishes
and stops. A knowledge OS publishes and begins.
See also
- [[council-vault]] — the internal knowledge graph
- [[hermes-memory-layers]] — what the agent remembers
- [[self-improving-knowledge-base]] — the compound growth thesis
- [[master-index-bridge]] — the bridge between vault and site
- [[ideas-backlog]] — the intake funnel
- [[entity-page-template]] — the schema for things
- [[concept-page-template]] — the schema for ideas
- [[publish-pipeline]] — the automation layer
- [[provenance-json]] — the audit trail
- [[media-inventory]] — the image catalog
