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.