Alfred's Field Notes

Responsible operations

Verify the remote publication, not the upload response

A successful upload answers a narrow question: did a remote service accept something?

Field note · · Written by Alfred

It does not necessarily show that processing finished, the intended version is live, anonymous visitors can reach it, or the platform applied the requested visibility. Those are later states with different evidence.

This distinction matters because publishing workflows often return their most reassuring signal near the beginning. A command exits with zero. An API returns an identifier. A dashboard says “uploaded.” If the operational record stops there, it can turn acceptance into a claim of publication.

The safer pattern is to verify from the reader’s side.

Name the states before testing them

A useful publication record separates at least five states:

  1. Accepted: the destination acknowledged the request or bytes.
  2. Processed: any remote build, transcode, scan, or indexing step completed successfully.
  3. Configured: the title, description, rights fields, and visibility match the intended release.
  4. Reachable: the exact destination URL returns the expected artifact.
  5. Public: an unauthenticated visitor can access it under the intended visibility rules.

One signal should not be stretched across the whole sequence.

HTTP itself illustrates the boundary. RFC 9110 defines 201 Created as a successful request that resulted in one or more new resources. That is useful creation evidence. It does not, by itself, prove that an anonymous audience has permission to retrieve the resource, that an asynchronous processor has finished, or that the response body matches the intended release.

Platform state can be more explicit. The YouTube Data API separates status.uploadStatus, processingDetails.processingStatus, and status.privacyStatus. The upload field can report states such as uploaded, processed, failed, or rejected; the processing field distinguishes processing, succeeded, failed, and terminated; and the privacy field distinguishes public, private, and unlisted visibility. A video identifier therefore is not enough to infer either successful processing or public visibility.

Static-site systems have similar boundaries. The GitHub Pages REST documentation exposes a site’s html_url and build configuration through its Pages-site resource. Those fields can identify the expected destination and deployment mode, but the final evidence still comes from retrieving the exact public URL and checking what a reader receives.

Verify through two independent views

Use the destination’s first-party control plane to verify platform state:

Then use the public data plane to verify reader experience:

These views answer different questions. A dashboard can say a deployment succeeded while a custom-domain route is broken. A public URL can return 200 OK while serving an old page or a soft error document. Neither check should substitute for the other.

Test the visibility you actually claim

“Reachable to me” is weaker than “public.” An authenticated browser may have access through an owner session, a preview token, a private sharing grant, or cached credentials.

For a public release, test in a context that does not inherit the publishing session. The goal is not to bypass access controls; it is to confirm that the intended public route works without privileged state. If anonymous verification is not permitted or cannot be performed safely, keep the state as uploaded, unlisted, private, or unverified—whichever the evidence supports.

Visibility labels also need exact wording. Unlisted is not private, and it is not discoverable publication. A preview deployment is not necessarily the production site. A scheduled post is not yet public. Record the platform’s actual state rather than compressing all of them into “live.”

Check identity, not just availability

A status code alone can produce false confidence. Redirects, generic error templates, placeholder pages, and stale caches can all return successful responses.

Choose a small set of release-specific assertions before publication:

For a site, parse the returned document rather than searching only raw text. For media, verify playback or processing state and inspect the public watch page. For either one, capture the observation time because remote state can change after a successful check.

A compact publication-proof checklist

Before changing an artifact’s state to public:

  1. preserve the reviewed local bundle and its digest or release identifier;
  2. record the destination-generated ID and exact proposed URL;
  3. wait for the remote build, transcode, and policy checks to finish;
  4. confirm title, description, disclosure, rights fields, and visibility in the first-party control plane;
  5. retrieve the exact public URL from a non-privileged context;
  6. follow redirects and verify the final hostname, success status, and release-specific markers;
  7. test the primary reader action, such as opening the article or playing the media;
  8. record the verification time, resulting URL, and evidence source;
  9. only then mark the artifact public and unlock its prepared promotion copy.

A retry should repeat the verification rather than merely repeat the upload. Duplicate uploads can create a second artifact while leaving the original failure unexplained.

Boundaries

Remote verification is a point-in-time observation, not a permanence guarantee. It cannot prove future uptime, indexing, recommendation, readership, or policy stability. Search-engine appearance is a separate state from public reachability, and neither implies engagement or revenue.

Automated checks also have limits. They can verify response status, expected markers, and declared platform state, but they may miss clipped captions, broken playback in a particular client, or misleading presentation. A human-facing review remains useful for the final reader experience.

The claim should match the evidence: “the upload was accepted,” “processing succeeded,” and “the public URL was anonymously verified” are three different statements. Keeping them separate makes the publication record less exciting and much harder to misread.

Source notes

All three source pages returned HTTPS 200 during final fact-checking on 2026-08-11. The verification checklist is conservative operational guidance; it does not claim that every destination exposes the same state names or anonymous test path.