WORK · PUBLIC DISCLOSURE

Designing a Truthful Content System

Turning editorial promises about privacy, visibility, references, and media into checks that can fail a build.

Content design and engineering

Cream paper shapes joined by dark threads, ending at a terracotta validation marker.

PROBLEM

What needed attention

Editorial rules written only as guidance are easy to forget when content grows or several tools can publish it.

CONSTRAINTS

What narrowed the decision

  • Preserve draft, unlisted, and public behavior across every discovery surface.
  • Reject broken or hidden relationships instead of silently omitting them.
  • Keep raw private media and unsafe metadata outside the repository.
  • Support rich writing without executable raw HTML.

RESPONSIBILITIES

Where the contribution sat

  • Define shared metadata and schemas for each collection.
  • Centralize route mapping, visibility filtering, relationships, and feed eligibility.
  • Build content and media validation around the documented publishing rules.
  • Provide authoring guidance for disclosure, alt text, captions, and evidence.

IMPORTANT DECISIONS

What was chosen and why

  • Treat visibility as behavior, not as a decorative status label.
  • Make references explicit pairs of kind and stable slug.
  • Fail verification on private trail targets, broken references, unsafe HTML, or future dates.
  • Audit image type, dimensions, file size, duplication, and GPS metadata before build.

A publishing rule needs a technical home

“Do not publish private material” is an important instruction, but it is not enough by itself. A growing site has many ways to reveal content: detail routes, collection pages, search data, feeds, topic pages, related links, trails, social cards, and the sitemap.

If each surface makes its own visibility decision, they will eventually disagree. The content system therefore has one shared model for route mapping, public filtering, reference resolution, related ranking, search documents, and feed eligibility.

This makes the rule inspectable. It also means one change can be tested against every consumer.

Visibility is behavior

AR/146 supports three states.

A draft is authoring material. It has no production route and appears in no public discovery output. An unlisted record has a direct route for deliberate sharing, but it uses noindex, nofollow and remains outside indexes, search, feeds, topics, trails, and the sitemap. A public record can enter normal discovery after validation.

The difference matters because “not linked from the home page” is not privacy. A hidden-looking URL can still be crawled, guessed, or included in a feed. The system must apply the same visibility meaning everywhere.

References should fail loudly

Relationships are stored as a content kind and a slug. This small structure is enough to resolve the right route while avoiding ambiguous names.

Before publication, validation checks that every target exists. Routable content may reference only public topics and public related records. Public trails may contain only public items. Trail cycles are rejected because a curated sequence should not lead back into itself.

I prefer this failure to a polite empty gap. Silently hiding a broken target makes the page appear healthy while the editorial intention has been lost.

Media needs its own boundary

Images carry risks that Markdown does not. A large original can damage the repository and page budget. A photograph can contain exact GPS data. A layered master can include private work that is invisible in the exported preview. A meaningful image without alt text can exclude a reader.

The repository accepts only web-ready raster sources in the content entry that uses them. The media audit checks supported formats, maximum dimensions, file size, duplicate bytes, and embedded coordinates. Technical camera information is shown only when it has been reviewed and entered into a public field.

The audit is a backstop, not permission to commit a private original. The safe workflow starts before the file reaches Git.

Rich writing without an execution path

Essays still need headings, code fences, lists, links, footnotes, figures, and callouts. They do not need arbitrary HTML. Raw HTML is rejected in every visibility state, which keeps the authoring preview and static renderer within a smaller, clearer boundary.

Structured fields carry the richer forms. A figure has an image, alt text, and a caption. A callout has a body and optional title. These fields are easier to preview, validate, and render consistently than open-ended markup.

The useful result

The content system does not decide whether a personal claim is true. That remains a human responsibility. What it can do is make the publishing promise harder to break by accident.

The repository now turns several editorial rules into executable checks. When those checks pass, they do not prove that the content is good. They do give the human review a cleaner and more trustworthy starting point.

OUTCOME & LESSONS

What changed or became clearer

  • Draft records have no production routes or discovery entries.
  • Unlisted records remain directly readable but use noindex and stay outside indexes and feeds.
  • Public relationships are resolved consistently across pages, search, feeds, and trails.
  • Content mistakes are reported with file-level messages before publication.

TECHNICAL CONTEXT

Tools and technologies

  • Astro Content Collections
  • Zod
  • TypeScript
  • Sharp
  • Exifr
  • Vitest

PUBLIC SEARCH

Find a path

Start typing to search the public index.