Pro RSS AI: design the review and publishing boundary

Give each stage a narrow responsibility

The retrieval stage obtains approved feed content and records where it came from. The preparation stage normalizes text and removes repeated entries. The drafting stage produces a proposed summary or classification. The publishing stage uses approved editorial records to generate the public feed and corresponding pages.

Store the result of each meaningful stage. If an entry is missing from a digest, those records let you ask whether it was never retrieved, excluded by a selection rule, rejected during review, or omitted from the final export. That is more useful than receiving a single generic pipeline failure.

Define reviewable states

A simple record can move through candidate, prepared, drafted, approved, and published states. Give rejected records a reason rather than silently deleting them from the workflow. A reviewer should be able to distinguish an irrelevant source from an unsupported model claim or a temporarily unavailable article.

• Candidate: the source record and its identifier are saved.
• Drafted: proposed text is linked to the exact input version.
• Approved: an editor has checked the intended public copy.
• Published: the feed and webpage resolve to the approved record.

Keep state changes separate from the model's prose. A generated sentence saying that an item is approved should have no effect on the publishing state. Approval belongs to the workflow's own controls and recorded editorial decisions.

Preserve identity through retries

Use a deterministic key for a source entry and the operation being attempted. A retry should produce another processing attempt for the same record, not a second public article. Preserve the approved copy until a replacement has passed the same review steps. Keep the original publication date distinct from the date of a new processing attempt.

The RSS specification describes the identifiers and publication fields in the final feed. Your internal processing records can contain more detail than that public format needs. Keep the public output focused on useful content and maintain operational history alongside it.

Test one failed retrieval, one unsupported draft, and one repeated publishing attempt before broadening the workflow. These cases reveal where responsibility is unclear. The feed API planning guide is a useful next step when separate components need a documented exchange format.