A Prompt Is Not Provenance

An AI can turn a page of notes into a convincing paragraph surprisingly quickly.

That is not the hard part.

The hard part is answering a future question: where did this claim come from, who owns the decision to publish it, and what happens when the source changes next week?

“The model saw it in the prompt” is not a useful answer. It is a memory of an interaction, not a source lineage.

For public writing, I have found a simpler division of responsibility useful:

raw material → curated knowledge → local draft → human publication

Each stage has a different owner. Trying to collapse them into one clever agent makes every later correction more expensive.

A knowledge base is input, not the publisher

A wiki is excellent at keeping small facts connected. It can point from a concept to a raw source, record related work, and make a future search possible. That does not make it the right place to own the blog’s accounts, routing decisions, publication checklist, or editorial voice.

Those belong with the repository that owns the outward-facing material.

This boundary is pleasantly unglamorous. The wiki remains a source of record for what was learned. The blog repository owns the draft format, the site route, the mirror target, and the final human review. Neither has to impersonate the other.

It also prevents a subtle failure mode: a general-purpose knowledge system slowly acquiring account-specific automation because it happens to contain good notes. Good notes should travel. Publishing authority should not travel by accident.

A sources field is a contract, not a scrapbook

Structured provenance needs a stricter rule than “put useful links somewhere.”

When a wiki page has a machine-readable sources field, that field should point to material the system can actually resolve in its ingest archive. It should not become a mixed bag of local paths, commit hashes, explanations, and every file someone glanced at while editing.

Those details can still matter. They belong in prose, where a reader can understand what was inspected and why it supports the claim.

The distinction sounds pedantic until automation reads the field. If the field sometimes means “ingested evidence” and sometimes means “miscellaneous supporting thoughts,” no tool can answer a simple question such as “can I open every listed source?”

Good metadata makes the boring question answerable. That is exactly why it survives contact with real workflows.

Drafting can be automated without automating authority

There is a seductive line of reasoning around writing automation:

1. The system can read the source.
2. The system can write the draft.
3. Therefore the system can publish it.

That last step is not a technical consequence. It is an editorial decision.

Public writing carries context a source file cannot fully encode: timing, tone, the audience’s current expectations, whether a comparison needs a screenshot, and whether a factual detail should be rechecked before it becomes permanent search-index material.

The human publish gate is not a ceremonial button at the end of an automated assembly line. It is where outward-facing responsibility remains visible.

The same is true for a hero image. Generating candidates can reduce blank-page friction. Selecting one is an editorial choice because the image becomes part of the post’s meaning before anyone reads the first heading.

The useful test is a correction test

Here is the test I now use for a writing pipeline:

If one claim is challenged six months later, can we trace it backwards without replaying an old chat?

A good answer has a path.

• The draft names the wiki pages it synthesized.
• The wiki pages point to ingested material.
• The blog repository retains the publishing contract and review steps.
• The public post is created only after a person reviews the draft.

That is more structure than a prompt. It is also less magic.

And when something must be corrected, less magic is a very good thing.