Building a Source-Faithful Hacker News Editorial Workflow

An automated news workflow can be technically reliable and still publish the wrong article. The feed request succeeds, the model returns valid JSON, the CMS accepts the post, and the schedule runs on time. Yet the final page may barely cover the story that triggered it.

That was the failure mode in our earlier Hacker News publisher. A real headline entered the workflow, but the prompt also supplied a bundle of unrelated trending stories and broad instructions about AI, automation, and Huygen Studios. The model responded to the combined theme instead of the selected source. A story about a specific GPT result could become a general article about the “future of automation.” The pipeline was operationally successful and editorially unsuccessful.

This article documents the architecture we now use to keep the selected topic in control.

Start with one editorial object

The workflow first creates a single source record. That record contains the exact Hacker News title, Hacker News item ID, discussion URL, outbound source URL, domain, score, comment count, and selection timestamp. Every downstream step receives that object.

The critical design decision is that other feed items are not passed to the writer. They can be used before selection to rank candidates or reject duplicates, but they are not writing context. Once a story is selected, the editorial scope narrows to one story.

This prevents a subtle form of context contamination. If five headlines are present, a language model often creates a synthesis even when asked to focus on one. Removing irrelevant context is more reliable than adding another sentence that says “do not mention the other stories.”

Fetch the primary source and the discussion separately

Hacker News provides two useful but different forms of evidence:

The linked page explains the claim, release, project, research result, or event.
The discussion reveals questions, objections, edge cases, and practitioner experience.

The workflow fetches both. The linked page is converted to clean text with navigation, scripts, cookie notices, repeated whitespace, and obvious boilerplate removed. The Hacker News item and comments are fetched through the public Algolia API. Comments are treated as discussion context, not verified facts.

That distinction matters. A source page can support a statement such as “the project is released under this licence.” A comment can support only a statement such as “some participants questioned the benchmark.” If a comment makes a technical claim that the source does not confirm, the article labels it as an opinion or omits it.

The fetch step also has a stopping rule. If the outbound page is inaccessible, nearly empty, or does not contain enough evidence to explain the headline responsibly, the workflow holds the item for review. It does not fill the gap with general background paragraphs.

Make title fidelity testable

“Write about the Hacker News topic” is subjective. A quality gate cannot evaluate it consistently. We replaced that instruction with a property the workflow can test:

In news mode, the output title must begin with the normalized Hacker News title.
The article body must contain one H1, and that H1 must match the output title.
The source record is retained beside the draft so the gate can compare them.

Normalization removes punctuation differences and collapses whitespace, but it does not replace the subject with a synonym. If the source is titled “Shackle: A pre-execution HITL gate for AI agents,” an acceptable title can add a clarifying suffix after that title. “A New Era of Responsible Agentic Systems” is rejected because the actual project disappeared.

The same rule is applied after any recovery rewrite. A common automation bug is to enforce constraints on the first draft and forget that a second model call can remove them.

Ask for an original contribution, not more words

Minimum word counts are a weak proxy for value. Our old parser appended stock sections when a draft was short. That made every article longer and the whole site more repetitive.

The new workflow never pads a draft. Instead, the writing prompt asks for at least one topic-specific contribution:

a worked example using the actual tool or claim;
a comparison with a named alternative;
a failure-mode analysis;
a decision table;
an annotated implementation sequence;
or a calculation that helps a reader evaluate the result.

The contribution must be supported by the source or clearly identified as the studio’s analysis. If the available material cannot support a useful article of roughly 800 words, the item is held. Publishing nothing is better than manufacturing apparent depth.

Separate evidence, analysis, and attribution

The article format is intentionally flexible, but each draft must make three layers understandable.

Evidence covers what the primary source actually says or demonstrates. Analysis explains consequences, limitations, comparisons, and practical context. Attribution gives readers the original source and Hacker News discussion links.

The prompt forbids copied passages and long quotations. The draft should paraphrase, link, and add context. It also forbids forced studio promotion. Huygen Studios does not need to appear in every introduction, section, and conclusion; the site header and byline already identify the publisher.

Use a deterministic gate after the model review

A second model checks accuracy, originality, source use, topic fidelity, repetition, and promotional language. That review is useful, but it is not the final authority. The workflow also performs deterministic checks:

required fields exist;
title and H1 fidelity pass;
source and discussion URLs are present in news mode;
the article has no duplicate H1;
the content clears the configured word threshold without appended filler;
quality and originality scores clear their thresholds;
the source-fetch stage did not report insufficient evidence;
and publishing credentials are private server credentials, not public keys.

The payload is prepared only when both layers pass.

Keep human review as the default

The rebuilt workflow defaults to dry-run mode. Automatic publishing is disabled, and human approval is required. A reviewer should open the source, compare the headline and central claims, test every external link, inspect the article for unsupported certainty, and confirm that the original contribution is genuinely useful.

Only after repeated test runs in both morning and evening modes should a team consider changing that default. Even then, sensitive topics, weak sources, and unusual claims should always be routed to a person.

The lesson is broader than Hacker News. Editorial automation becomes safer when the system reduces ambiguity before generation, retains provenance through every node, tests the promises made by the prompt, and allows a weak source to produce no article at all.