Moving a file should not publish it

The tempting version of content automation is almost frictionless: inspect recent work, find an interesting lesson, write a piece, and put it online. Every extra review step looks like something to remove.

That is also the version I would trust the least.

A writing agent can produce a fluent draft while misunderstanding the importance of a correction, overstating a project’s maturity, or including a detail that was safe inside a private working conversation but not on a public portfolio. The risk is not limited to bad prose. The agent is converting messy operational evidence into a public claim about my judgment and my work.

So when I built Field Notes, I treated publication as an authority boundary rather than the last step in a file workflow.

Drafting and publishing are different powers

The site stores unpublished and published Notes in separate directories. That is useful, but a directory name is only one signal. A public Note must also declare a published status and appear in an explicit loader used by the application. Drafts are never discovered automatically by scanning the filesystem.

This means moving a file is not enough. Changing its metadata is not enough. Writing a plausible URL is not enough. Publication requires a deliberate combination of changes that a reviewer can see.

This is more than defensive programming. It makes the editorial workflow legible. The automation can own discovery, evidence collection, and a new MDX draft. I retain authority over whether its interpretation is accurate, whether the writing sounds like me, and whether the piece deserves a place in the public archive.

That separation also makes rejection cheap. A candidate can end as “no note” because the lesson is weak, repetitive, private, or already covered. Nothing has to be unpublished. No public correction is required merely because an automated run felt obliged to produce something.

The public site should know less

A common implementation would scan every MDX file, filter on a status field, and render the published ones. That can work, but it gives the public build visibility into material it does not need. One forgotten filter or alternate route can turn private draft text into an accidental feature.

The Field Notes loader takes the narrower approach: it knows the small set of approved modules by name. Draft storage exists for the authoring workflow, not for the runtime.

The distinction matters to nontechnical stakeholders too. A founder would not give a copywriter automatic authority to change pricing because both tasks happen in the same content system. A product manager would not treat an internal experiment as a launched feature because it exists in the repository. A recruiter should not have to guess whether a confident portfolio claim describes a tested result or a generated interpretation.

The technical controls support a very ordinary business requirement: someone accountable approves what the organization says in public.

Verification is part of the boundary

An explicit approval step can still fail if the system exposes drafts through side doors. The Notes build therefore checks more than whether MDX compiles. It confirms that each published slug has a static route, that the archive routes exist, and that known draft markers do not appear in the exported site. Unknown and unpublished Note URLs resolve to a useful 404 with a noindex instruction rather than an empty response or a half-rendered article.

That last behavior produced its own lesson. The local 404 worked, but the first hosted release returned the correct status with an empty body. The build adapter had to embed the designed document and verify its actual content. A correct status code was necessary evidence; it was not the complete visitor experience.

The same principle applies to the automation itself. A successful run should not be measured by “one file created.” It should report which evidence was used, which details remain uncertain, what checks passed, and whether the outcome was a draft, a consolidation suggestion, a revision suggestion, or no note at all.

1. 01Find an evidence-backed lesson
2. 02Write only to the draft boundary
3. 03Validate structure and substance
4. 04Review facts, privacy, and voice
5. 05Publish through explicit gates
6. 06Verify the exported experience

There is intentional friction here. It is small enough that publication remains practical and visible enough that it cannot happen by accident. Automation removes the repetitive work of searching, organizing, formatting, and checking. It does not remove the decision that carries reputational authority.

The strongest automation is not the one with the fewest steps. It is the one that can do useful work unattended while making its worst plausible mistake boring: an imperfect private draft that waits for review.