Archive note, September 29, 2025: This post follows the September 2025 SoCalNomad workflow-design notes.
The first serious SoCalNomad automation problem was not writing articles.
It was deciding what did not deserve to become one.
The early ambition was obvious enough: collect Southern California entertainment stories from many sources, filter them, synthesize useful coverage, and publish through WordPress. The trap was also obvious once I looked at the data. Entertainment news does not behave like national hard news.
There often are not five independent articles about the same small concert announcement, venue update, or local cultural event. Sometimes the most relevant item is a single source with a useful fact. If the system required traditional multi-source overlap at the wrong stage, it would throw away exactly the local material SoCalNomad needed.
The Geographic Boundary Came First
The content boundary was deliberately narrow:
- Los Angeles County.
- Orange County.
- Inland Empire.
- San Diego County.
- Live events, venues, artists, cancellations, festivals, and local entertainment culture.
That meant broad entertainment coverage was not enough. A celebrity story without a local event hook did not belong. A film item with no reader-actionable Southern California angle was noise. A venue closure in the coverage area mattered more than a national headline with no local consequence.
The filter had to understand the publication before it could help the publication.
Similarity Was The Wrong First Question
Early workflow thinking spent time on article matching and similarity. That is a natural instinct if you are building a news aggregator. Find similar articles, cluster them, write the summary.
For SoCalNomad, the better first question was relevance.
Does this item describe something a Southern California entertainment reader can attend, care about, or use?
That moved the system away from simple similarity matching and toward entity extraction: artists, venues, dates, cities, counties, event types, and source context.
Once the entities existed, the project could support more than news posts. The same extracted facts could feed a calendar, directory pages, artist profiles, and internal linking.
Cost Control Was Architectural
The early design used a two-tier model:
- A cheap or local model would reject obvious noise.
- A stronger model would work only on material that survived.
That was not just thrift. It was architecture.
AI workflows become expensive and unreliable when every item is treated as equally worthy of attention. Filtering first changed the economics. It also made debugging easier. If a bad article appeared later, I could ask whether the failure happened in relevance filtering, clustering, synthesis, or publishing.
That separation became a recurring design pattern across SoCalNomad: do not ask one black-box step to make every decision.
Review Was Built In
The first workflow design did not assume full autopublishing from day one.
It planned for a review gate:
- Draft mode while trust was low.
- Autopublish only after repeated success.
- A simple operational switch rather than a philosophical commitment.
That mattered because automation for a publication is not just a technical system. It is an editorial risk surface.
The system needed to know the difference between “this is relevant,” “this is publishable,” and “this should go live without a human reading it.” Those are three different claims.
The Real Product Was A Pipeline
Looking back, the important artifact from that period was not a finished article generator. It was a pipeline shape:
RSS feeds came in. Local relevance was evaluated. Entities were extracted. Stronger synthesis happened later. WordPress publishing sat behind a review decision.
That sounds ordinary now, but it was a significant correction. I stopped trying to make the first version clever and started making it staged.
The first newsroom was not a writer.
It was a filter that understood what the site was for.