A public article should not be copied straight out of a chat.

If the article comes from a long-term knowledge base, it should pass through three layers first: evidence, wiki, and publication.

This is not process for its own sake. It prevents three common failures: lost sources, misread project facts, and private material leaking into public writing.

First: preserve evidence

Knowledge formation starts with evidence, not summary.

Evidence can be a web page, paper, project document, code audit, product research note, meeting record, or local retrospective. It may not be public-safe. It may not be stable. But it is the source of later judgment.

At this stage, the important rules are:

  • do not rush to polish
  • preserve the original context
  • record source and date
  • separate fact, inference, and opinion

AI can help organize evidence. It should not make an AI-cleaned summary look like the original fact.

Second: compile into wiki knowledge

The evidence layer answers “what material do we have?” The wiki layer answers “what have we learned that is stable?”

Codex acts as a compiler here. It turns repeated patterns, concepts, methods, and judgments into linked knowledge objects.

A project retrospective may become a concept. Several product research notes may become an evaluation framework. A publishing mistake may become a boundary rule.

The wiki layer should aim for:

  • clear concepts
  • traceable sources
  • links to related pages
  • no blind copying of project-local detail
  • no promotion of temporary judgment into long-term principle

This layer can be browsed in Obsidian and queried later by Codex.

Third: write a publication source

The wiki is not the public article.

The wiki is written for the knowledge system. A publication source is written for readers. The audience, privacy rules, structure, and tone are different.

A publication source should answer:

  • Who is the reader?
  • What should the reader understand or do?
  • Should this be an essay, tutorial, note, project page, or interactive page?
  • Does it need Chinese and English siblings?
  • Which sources are public-safe?
  • Does it belong to a series?

This is not just title editing. It is a rewrite from internal knowledge to reader-facing argument.

Let AI propose, but do not let it silently write the durable layer

Some public tools use a similar review-queue idea. Tracekeeper, for example, emphasizes that AI can suggest maintenance changes to an Obsidian vault, but reviewable traces should remain before those suggestions become durable knowledge.

That principle matters even more for publication.

AI can compile evidence into wiki knowledge and rewrite wiki knowledge into a publication source. But the move from suggestion to durable knowledge, and from durable knowledge to public article, should have an explicit status. It should not be a silent overwrite.

In my pipeline there are at least two gates:

project evidence -> central review/promote -> wiki/source draft
publication source -> prepare/review -> site artifact

The gates are not there to slow the system down. They preserve accountability.

Fourth: prepare and review

A publication source still should not go directly into the site.

First create a candidate:

kb publish prepare <source>

Prepare creates the candidate record, public draft, source snapshot, manifest, and initial review file. For a bilingual site, the language adaptation work also belongs here.

Then review:

kb publish review <candidate-id>

Review checks:

  • local paths
  • private material
  • missing language siblings
  • metadata alignment
  • source hash validity
  • collection and series fit

This step matters because well-written AI text is not automatically public-safe.

Fifth: sync to the site

After review, sync to the publication node:

kb publish sync <candidate-id>

Sync does not translate or invent facts. It serializes reviewed candidates into generated artifacts the site can render.

The site owns build, routes, layout, language switching, and deployment. The source remains in the central knowledge base.

If a public page is wrong, first identify the layer:

  • If the content fact is wrong, fix the central source or candidate.
  • If routing or layout is wrong, fix the site.
  • If the project fact is unclear, return to the project directory.

A public article should be traceable

A healthy publication pipeline can answer:

  • Which source draft produced this article?
  • Which wiki concepts or project evidence supported it?
  • When was the candidate created?
  • What did review check?
  • Where was it synced?
  • Is the site artifact draft or published?

That is why I do not write public articles directly inside the site repository.

The site is a publication node. It is not the knowledge source of truth. A serious knowledge system preserves the chain from evidence to compilation to public draft to generated site artifact.