The publication has four surfaces

A reader opens the homepage and sees a publication. A loyal subscriber opens the feed and sees another. A researcher uses the archive and finds a third. A crawler reads the sitemap and receives a fourth. Each surface is valid markup. Every link it contains works. Yet the sets of articles do not agree, and therefore the publication has no single public account of itself.

This drift is easy to create. A homepage has a hand-maintained limit. An archive was generated before the latest batch. A feed applies a future-date filter that the server does not. A sitemap walks the filesystem and includes pages no editorial surface acknowledges. Nothing crashes. The failure is semantic: each interface answers “what has been published?” differently.

The interfaces serve different purposes, so perfect visual symmetry is unnecessary. A homepage may feature a selection, a feed may contain only recent entries, and a sitemap may cover stable utility pages as well as essays. But those differences should follow declared rules over one underlying inventory. When they arise from separate lists and ad hoc scripts, omissions become invisible.

Discovery files are public commitments

Teams sometimes treat feeds and sitemaps as secondary outputs for machines. They are closer to contracts. A feed tells subscribers what is new and gives software the metadata required to order it. A sitemap tells crawlers which canonical URLs the publisher wants discovered. An archive tells people what the publication remembers. The homepage tells newcomers what the publication chooses to foreground. Together they create the public shape of the corpus.

The formats carry their own semantics. RFC 4287 defines Atom entries and their identifiers, links, publication times, and update times. The Sitemaps protocol defines URL entries and optional metadata such as last modification. These are not interchangeable fields. Generating syntactically valid XML with invented or inconsistent facts merely makes a contradiction machine-readable.

A publication is not complete when every page exists. It is complete when every public surface can account for the same body of work under an explicit rule.

The strongest design begins with a normalized content inventory. Each item has one stable identifier, canonical URL, title, publication state, actual release time, significant modification time, and any classification used for presentation. The homepage, archive, feed, and sitemap are projections of that inventory. Their selection rules live in code and are tested. No projection maintains a second authoritative list.

This does not require a database. A directory of well-structured source files can be an inventory if the build parses every item, rejects duplicate identifiers, and produces every downstream surface. The key is that one enumeration step decides which items exist. Separate generators may render different formats, but they receive the same facts.

Count the disagreements, not just the errors

Ordinary link checks ask whether referenced pages return success. Cross-surface validation asks whether the sets agree. Every essay intended for public discovery should appear where the policy says it should. Every feed entry should resolve to one canonical essay. Every sitemap essay URL should correspond to an inventory item. Every archive item should carry the same title and release date as its page.

Counts are an efficient first alarm. If the corpus contains 400 published essays, the complete archive should not contain 230. A feed intentionally limited to 50 should contain 50, and its selection rule should identify which 50. Counts do not prove correctness, but unexplained differences reveal where to look. Set comparisons then identify the missing and extra identifiers.

Time adds another axis. Google’s guidance on XML sitemaps and RSS or Atom feeds emphasizes correct modification times and canonical URLs. A generator should not stamp every item with the build time, because rebuilding the site did not republish every argument. The inventory should distinguish content changes from mechanical regeneration.

Ordering should be tested too. Same-day items need a stable secondary key. Otherwise a rebuild can reshuffle the feed or archive without a content change, causing subscribers and caches to interpret old entries as new. Stable identifiers prevent duplication, while deterministic ordering makes differences reviewable.

A complete audit also checks the negative space. Drafts should appear on none of the public surfaces. Retired aliases may redirect but should not masquerade as canonical entries. Utility pages may belong in the sitemap but not the essay archive. Each exception needs a named category rather than a one-off omission.

Once the surfaces come from one inventory, editorial work becomes simpler. Publishing an essay is a state transition that updates every appropriate projection. Removing it is another governed transition. The archive no longer depends on someone remembering a separate step, and the feed no longer has to infer publication from a filename.

Observability should remain tied to editorial meaning. Monitor the number of published inventory items and the number represented on each complete surface. Alert on unexpected set differences, duplicate canonical URLs, malformed feed entries, and modification times later than the build’s verified clock. These checks are cheap compared with discovering months later that subscribers and search engines received only half the corpus.

Readers may never compare the four surfaces directly. They still experience their agreement. A reliable feed builds the habit of subscription. A complete archive makes old work usable. An accurate sitemap makes the corpus discoverable. A coherent homepage makes the current argument legible. Check those agreements on every release. Their consistency is not a technical nicety; it is the publication keeping one account of what it has said.

— Dispatches · Summit Cognitive