DEV Community: yocho — Hikaru Sato

When AI-Generated Articles Fail, Keep the Body and Repair Only What Broke

yocho — Hikaru Sato — Mon, 14 Sep 2026 12:18:22 +0000

The dangerous failure in AI publishing is not that a model gets one request wrong. It is losing track of what already succeeded, what was charged, and what is safe to run again.

While building YOCHO, an AI-industry intelligence service, we changed the editorial pipeline around that problem. The body, summary, and title are separate phases. A failed summary does not throw away a valid body. A bad title does not trigger a full rewrite.

You can see the current product at https://yocho.ai.

What I built

The pipeline is intentionally boring:

source snapshot
  -> body generation
  -> body checkpoint
  -> summary generation
  -> title validation or title-only repair
  -> final publication transaction

Before a generated result is considered publishable, we store a private draft receipt tied to the call ID. It contains the source digest, response digest, phase, cost receipt, validation result, and any title correction. It does not contain API keys, HTTP headers, or an unbounded provider response.

The checkpoint lets a later phase reuse the exact body instead of asking the model to recreate it.

Why failure states need different treatment

A known failure and an unknown failure are not the same thing.

A known failure means that the provider response and its billing outcome are settled. If a summary fails validation in that state, we can retry only the summary once under the shared rate and cost controls.

An unknown failure is a timeout, connection loss, or an unsettled billing result. We keep it on hold and do not automatically send the request again. The missing response might still exist on the provider side. Retrying blindly can create duplicate work and duplicate charges.

This is less about being conservative for its own sake than about preserving a truthful state machine.

A concrete example: the title is wrong, the body is fine

Corporate disclosure pages are a useful stress case. A generated title may contain a number that is not in the source, an ambiguous company name, metadata such as a URL or JSON fragment, or an English source headline where a Japanese title is required.

The safe response is not to regenerate the article. First, construct a source-grounded title from the retrieved issuer name and listing title, then run the same title validator again. If a Japanese title still needs model assistance, run a title-only phase against the stored body and source identity.

In the September 14, 2026 bounded rescue, the fixed target was 95 tasks. Stored bodies were reused, and 43 earlier title substitutions were corrected while preserving the body and summary. That number is deliberately not presented as completion of the entire 3,356-task manifest.

What I learned

Checkpoints are more valuable than optimistic retries

Without a checkpoint, every failure becomes a full regeneration. With one, the system can ask a smaller question: “Is the summary the only thing that needs work?”

The final database transaction is part of the quality gate

Provider-side validation is not enough. The publication transaction can still expose a stale source, a malformed title, or a mismatched identifier. The same contract must be applied again immediately before the status changes to published.

Completion is not the same as an empty pending queue

A queue with no pending items may still contain holds or in-flight work. We distinguish queue_empty from queue_drained, and we keep the oldest wait time and remaining budget visible.

What is next

The next question is not whether we can generate more articles. It is whether we can measure the complete path honestly: source freshness, time to publication, checkpoint reuse, known and unknown holds, confirmed cost, and the reasons final validation stopped a draft.

That is the direction behind YOCHO: let AI extract, classify, and propose, while keeping the boundary where evidence becomes interpretation visible. The live project is at https://yocho.ai.

This is an implementation and operations note as of September 14, 2026. It does not claim perfect factuality, search ranking, readership, or AI-answer inclusion.

What I Learned Turning an AI News Crawler into a Working Product

yocho — Hikaru Sato — Wed, 09 Sep 2026 04:38:21 +0000

Fetching an article is only the beginning of a news pipeline. The harder work is deciding whether the response is an article, whether it belongs in the product, and whether a reader can understand what was published.

I am building yocho, an AI industry news and analysis service. This is an architecture note about the work between acquisition and publication, based on the implementation and operational checks available on September 9, 2026. It is not a benchmark or a claim that every item in the collection has been processed successfully.

What I built

The service brings category-based news browsing, Japanese editorial articles, and public analysis posts into one application. Its subject matter extends from AI models to chips, infrastructure, power, and business developments.

The backend uses FastAPI and Python for database access and domain logic. PostgreSQL holds application data and the job queue; GCS holds raw archives. The Next.js frontend accesses the backend rather than connecting directly to the database.

That division matters because publication rules need to stay consistent across a news page, a mixed news-and-analysis feed, and background processing. A frontend rendering successfully cannot establish that a document passed those rules.

Why fetching is a separate milestone

A successful response answers a narrow question: did the server return something? It does not establish that the response contains a usable article.

A collection pipeline has several distinct decisions:

Discover a candidate URL.
Fetch and retain the source material.
Extract the article content.
Determine relevance and category.
Prepare the editorial representation.
Apply publication conditions.

This list is a conceptual model, not a literal function call sequence. Its value is that each step can fail independently and needs its own observable outcome.

For example, a URL may return a listing page containing many headlines. Treating that response as one article creates a plausible-looking record with the wrong unit of content. Another page can contain a real article while still being unsuitable for the service's editorial scope.

What I learned about classification

One concrete correction in the recent commit history separates energy storage from computer memory. The shared word “storage” is not enough to decide where an article belongs.

A useful regression case therefore includes context: batteries and power infrastructure in one example, memory devices and computing in another. The expected result is a meaningful category distinction, rather than merely proving that a keyword was detected.

The broader lesson is to test confusing neighbors. A classifier can look reasonable on obvious positive examples and still damage the reader's experience at category boundaries. For a developer applying this elsewhere, collect a small set of near misses before expanding the source list.

What I learned about retries

The current article automation generates the body and a dedicated feed summary, then commits publication and task completion in the same database transaction. That boundary prevents those two database outcomes from being recorded independently.

It does not make the whole workflow one atomic operation. The external generation request happens outside that transaction. A provider can rate-limit a request, and accounting and retry state still need to survive that interruption.

Operational checks recorded rate limiting and subsequent successful processing. That supports a bounded statement about recovery in those checks. It does not establish that the entire backlog is finished or that every future provider failure will recover automatically.

For another queue-backed application, the practical question is: after an interruption, can the next worker distinguish work that needs retrying from work already published? Write down that state transition before increasing concurrency.

What is next

The public product now has more of the reading journey in place, but completeness and quality remain separate goals. More source coverage does not guarantee a useful stream in every category. A generated summary also needs its own review; assembling fragments from the article can produce repetition rather than a good introduction.

I also want to evaluate the transition from news to a reader's own analysis. That is a product hypothesis, not an observed adoption result: preserving sources and interpretation separately may make reasoning easier to revisit. The test is whether someone can recover the original evidence and explain what would change their conclusion.

Open yocho and inspect one news item's title, category, editorial text, and source link as separate outputs. That same small audit is a useful starting point for testing your own crawler.

Why I’m Building yocho: From Events to Hypotheses

yocho — Hikaru Sato — Wed, 12 Aug 2026 03:42:03 +0000

AI industry news is abundant, but information alone does not make the next change easier to understand.

I’m building yocho.ai, an AI industry intelligence system that keeps four layers distinct:

Event: what happened
Entity: who or what is involved
Relationship: how changes connect
Hypothesis: what may follow and why

This boundary is practical. Facts can be corrected, relationships can be re-evaluated, and hypotheses can change as new evidence arrives. An AI system should help organize the evidence without silently turning its own interpretation into an official conclusion.

I’m starting with a founder build log covering design decisions, implementation lessons, discarded approaches, and open questions.

If you are interested in evidence-led AI industry intelligence, I’ll share more as the system develops.

Learn more: https://yocho.ai

A concrete example

For illustration, imagine Company A releases Model B. yocho keeps the layers separate:

Event: Company A releases Model B.
Entity: Company A, Model B, and competitor Company C.
Relationship: Model B may change Company C’s pricing strategy.
Hypothesis: Lower inference costs may change how teams evaluate adoption.

A simple flow is: Source → Event → Entity / Relationship → Hypothesis → Review. The hypothesis is provisional, not a fact. New evidence can support it, weaken it, or leave it unresolved.

What’s next

I’m using yocho.ai as the canonical hub for the product’s design decisions, evidence, and implementation updates. The next useful step is to compare a hypothesis with the sources and relationships that support it.