Building a Source-Grounded Codex Article Pipeline Without Publishing Unverified Claims

Why this matters

An AI-assisted technical article can sound credible long before it is credible. That risk is especially sharp when the article describes code, tests, or publishing behavior that the author did not inspect or run.

I wanted a workflow that treats an article like a small engineering deliverable: collect evidence first, record the experiment, validate the Markdown, and make a platform draft only after an explicit decision. The useful output is not a faster first draft. It is a reviewable explanation that can be traced back to a repository and a recorded command.

What I built or tested

I used the blog-publisher repository as the test subject and extended a Codex skill that writes source-grounded technical articles. The workflow creates a private work directory beside the article, then requires:

1. a claim ledger with source locations;
2. an experiment record with commands, limitations, and verification;
3. publisher-compatible source.md front matter;
4. a structural validator that runs the publisher's dry-run; and
5. an explicit --publish flag before it can create a DEV.to draft.

The publisher already parses front matter, restricts article images to relative local paths, renders Mermaid, and has a dry-run path that uses in-memory publication state and preview storage. That makes it a useful boundary for validating the article before the DEV.to API sees it.

Setup

The repository requires Node.js 22 or newer. I installed its dependencies and used the existing commands:

npm run check
npm test

For the article workflow, I scaffolded the article directory with its title, slug, and repository path. The scaffold writes source.md plus a private .work/ directory. The work directory is deliberately ignored so terminal details and evidence notes do not become accidental publishing inputs.

Step-by-step walkthrough

First, I captured the implementation facts that matter to the article. The Markdown parser accepts the title, slug, description, tags, publication state, and enabled platforms from front matter. The publish path switches to memory-backed state and preview storage when dry-run is selected. DEV.to receives no more than four tags.

Second, I recorded the experiment rather than claiming that a test was run because a test file exists. The record carries the exact commands and the result expected from each validation step.

Third, I used a small validator before handing anything to the publisher. It checks the article structure, the private evidence file, the experiment record, local-image policy, and a few common credential patterns. It then invokes the publisher wrapper without --publish.

The important ordering is that the dry-run finishes before the only command that can create a platform draft.

What went wrong

The earlier handoff wrapper only performed a dry-run when --dry-run was supplied. Its default path rendered the article, prepared assets, and then created or updated a draft. The skill said to validate before a network write, but its sample draft command did not make that safe path the default.

That is a workflow failure rather than a model failure. A careful instruction can still be skipped when the command-line interface makes the risky action easier to invoke than the safe one.

Fix or mitigation

The wrapper now treats the absence of --publish as a dry-run. A draft requires both an explicit platform and an explicit network-write flag:

node /path/to/publish-generated-article.mjs \
  --publisher /path/to/blog-publisher \
  --article /path/to/article/source.md \
  --platform devto \
  --mode draft \
  --publish

The article validator intentionally calls the same wrapper without --publish. That makes the no-network check part of the standard workflow instead of a reminder that an author can forget.

Trade-offs

The validator can prove that an evidence record exists, but it cannot decide whether every sentence is a fair interpretation of the source. Human review still matters for causal claims, omissions, and reader-facing advice.

The private ledger also makes a deliberate trade-off: it improves traceability for the author without automatically becoming a public artifact. A public repository, template, or minimal example should be added only after its code and history are safe to share.

This first version is DEV.to-only. It does not claim to solve canonical URLs, cross-posting, social distribution, analytics, or platform-specific content strategy.

How I verified it

I verified the workflow in three layers:

1. TypeScript checking and the repository's existing test suite validate the publisher implementation.
2. The article validator checks this article's front matter, sections, evidence ledger, experiment record, and local asset policy.
3. The validator runs Mermaid rendering plus the publisher's dry-run, which produces the final Markdown payload without calling a publishing API.

After those checks, the same wrapper can create a private DEV.to draft. The draft is not a public release and remains subject to an editorial review in the DEV.to dashboard.

AI assistance disclosure

Codex helped structure and draft this article. The technical claims were checked against the local repository and the recorded validation commands; the workflow does not treat generated prose as evidence.

Conclusion

The durable unit of AI-assisted technical writing is not the prompt. It is the evidence-and-verification loop around the prompt.

Before publishing your next engineering note, create a small claim ledger, record the command that proves the behavior, and make the safe publishing path the default. Those three habits make a generated draft easier to trust, update, and hand to another engineer.