Since I started using AI, getting a draft into its first usable shape has become much faster. Outlining, organizing sources, reworking phrasing — all quick now.
I still stop at the publish button. Is this number still current? Have official statements and my own observations blurred together? Does that link actually support the claim I attached it to?
“The draft is finished” and “this is safe to publish” turned out to be different states.
So I built the Source-to-Publish Evidence Gate: claims, evidence, and volatile facts recorded together, with the publication decision closed as PASS or HOLD.
This does not make AI-written articles correct automatically. It makes visible where a human has to check, so the decision — publish, or hold — can actually be closed.
Originally published in Japanese on September 4, 2026. This English version was written in September 2026.
What got faster was drafting, not deciding
Hand an AI your material and you get extracted key points and a structure back in minutes. Comparing several angles is easy. Tightening long prose is easy.
The trouble is that the more readable the output, the more publishable it looks. Reading naturally and being adequately supported are not the same property.
OpenAI’s own terms of use note that output is not always accurate and that people need to evaluate accuracy and appropriateness before using or sharing it. That is general guidance for using OpenAI services, not an endorsement of anything I built.
What I wanted to fix was not AI’s writing ability. It was the operational question sitting in front of a fast draft: who checks what, before the publication decision can be closed?
More sources did not close the decision
My first instinct was that more reference URLs would settle it. Official pages, specifications, primary material, results I had actually run — the more you list, the more substantiated it looks.
Counting URLs decides nothing. Is a pricing claim backed by an outdated product page? Has something that happened in my environment been generalized into a specification that applies to everyone? Is information that needs a verification date written as if it were permanent?
Google Search Central makes a related point: generative AI can help with research and structure, but accuracy, quality, relevance, metadata, and structured data still need checking, and readers should be told how the content was produced. Again, not a claim that any particular tool improves search performance.
Gathering sources and deciding which source supports which claim are two different jobs. The second one stayed vague in my process, which is why pre-publication checking kept looping back to the start.
What it does, and refuses to do
The Evidence Gate operates on a manifest you provide: source types, publicly shareable URLs, the claims used in the article, facts likely to change, and verification timestamps, recorded against a fixed schema.
The engine checks whether that input satisfies the configured rules. Missing something returns HOLD; conditions met returns PASS. The same result is written to Markdown and versioned JSON.
It does not fetch source content. It does not search, does not extract claims from your draft automatically, and does not publish to a CMS. PASS is not a certification of truth, legal compliance, or authorship.
A human enters the verified information. A human decides whether it may be published. The Evidence Gate mechanically catches the gaps between those two.
Manifest to PASS or HOLD, in one line
The flow is: public-safe manifest → claim ledger → Markdown and JSON report → PASS or HOLD.
The manifest holds only source URLs and claims that are safe to expose. The claim ledger lines up which assertion is supported by which kind of evidence, whether the fact is volatile, and whether it was re-verified before publication.
Running the engine produces human-readable Markdown and machine-usable JSON carrying the same gate result, so a reviewer’s reading and downstream processing do not diverge.
The important design choice was not scoring. Not “82 points, publish it,” but HOLD because something is unverified, or PASS because conditions were met — with the reason recorded. The reason you did not publish stays readable afterwards too.
Walking a synthetic fixture from HOLD to PASS
I ran a synthetic fixture with fictional product data through the real engine. Keeping sources, claims, and mode identical, I removed only the verified_at timestamp from a piece of volatile version information.
Result: HOLD, exit 3 — because a volatile fact was unverified. That is not a processing failure; it is an intentional exit designed to stop publication.
Re-checking the original information, adding verified_at, and re-running the same engine produced PASS, exit 0. The draft was not rewritten to slip past the check. The state changed because a missing verification was completed.
Why it runs offline on public-safe URLs
A pre-publication manifest accumulates judgments you are not ready to expose. So the core engine runs offline after download: it does not fetch URLs and sends no telemetry.
“Offline” here does not mean no network is ever needed — downloading the wheel or archive requires one. It means the engine, once obtained, does not reach out.
I did not accept another model’s review as correct
During development I asked Claude for a single read-only cross-model review. It returned findings about onboarding and artifact mismatches, handling of local URLs and queries, and error stability.
I did not turn those answers directly into fixes. Material items were reproduced on my side with Codex, and only what I could confirm was changed.
Independent QA after those fixes then found a false positive: valid alphanumeric domains were being rejected. Even after acting on another model’s findings, a human had to verify with real input. The Evidence Gate itself was closed the same way — review, author reproduction, and independent QA kept separate.
Who this suits, and who it does not
It suits people producing technical articles, product comparisons, or research pieces with AI on an ongoing basis. The more an article depends on pricing, versions, regional availability, or terms that need re-checking right before publication, the more a recorded HOLD reason is worth having.
It does not suit people who want sources gathered automatically, drafts fact-checked automatically, or publication to a CMS fully unattended. Building the input manifest is real work, so a short diary post with almost no volatile information does not need this.
The free core is MIT licensed and enough to reproduce a decision. There is also a paid workflow pack — as displayed on the product page on September 3, 2026, a $29 one-time private beta, limited to five buyers, single-user, usable on up to three devices the buyer owns, including all 0.x updates. Those were that day’s displayed terms. I have not verified sales figures, user counts, or outcomes elsewhere, so I am not stating any.
Start by producing one HOLD
You do not need to migrate your whole article process into a manifest. Run the free core’s sample, remove one verification timestamp from a volatile fact to get a HOLD, then restore it and move to PASS. That round trip is enough to start.
What it shows you is not that your article is true. It is whether you can explain, in a consistent form, what was missing and what you verified before proceeding.
The faster AI makes your writing, the more you need something that stops you before publishing. What I wanted was not automation that removes human responsibility, but a mechanism that narrows the decision down to where a human can actually take it.