A workflow is not truly repeatable if it only makes sense to the person who built it.

This is especially important when AI is involved. A prompt may produce different wording on another run. A product page may change. A browser edit may save only part of a block. If the process record contains nothing more than “used AI to make the page,” no one can verify what happened.

Good documentation does not need to capture every click. It needs to preserve the decisions and evidence that determine whether the result can be trusted.

Start with the intended outcome

Write the outcome in observable terms.

Weak outcome: “Improve the homepage.”

Verifiable outcome: “Restore one clean header, add Field Notes to the navigation, and replace four static article cards with a newest-first Query Loop that does not overflow at 390 pixels.”

The second version tells a reviewer what to inspect. It also prevents extra changes from quietly entering the task.

Record the starting state

Before editing, note what exists and what is wrong. This can be a short list, a screenshot, a revision identifier, or a saved copy of the content.

For a website change, record:

  • public URL
  • page, template, or template part being edited
  • visible problem
  • last known-good version when available
  • content or links that must be preserved

For an article, record the proposed title, audience, purpose, sources, and any claims that still need verification.

This starting snapshot separates an existing issue from a problem introduced during the work.

Separate inputs from instructions

An AI workflow often includes source material, user requirements, and generated suggestions. Label them clearly.

For example:

  • User requirement: no em dash characters in published copy
  • Source: official WordPress Query Loop documentation
  • Existing asset: approved ElevenLabs affiliate URL
  • Generated proposal: a six-article content cluster
  • Human decision: publish the posts across six dates instead of all at once

This prevents generated text from being mistaken for an authoritative source. It also protects exact inputs, such as approved tracking links, from accidental rewriting.

Keep a decision log

A decision log explains why one option was selected.

It can be brief:

  • Chose a Query Loop because the article library will keep growing.
  • Kept the existing color palette because desktop and mobile checks passed.
  • Restored the complete header revision because the current block structure was malformed.
  • Did not publish product performance claims because no hands-on test was completed.

The goal is not to defend every preference. It is to preserve decisions that affect accuracy, maintenance, or future changes.

Define pass and fail checks before execution

Verification gets weaker when the standard is invented after seeing the result.

For the SideQuestStack homepage repair, useful pass conditions included:

  • exactly one logo
  • expected navigation labels present
  • newest articles shown in the correct order
  • one H1
  • no invalid blocks
  • document width no greater than viewport width at 390 pixels

For an AI-assisted article, pass conditions may include:

  • every factual claim has a current source or direct evidence
  • no invented first-person experience
  • all links open the intended destination
  • affiliate relationships are disclosed
  • title, excerpt, category, and slug are present
  • no em dash characters

Clear checks turn “reviewed” into something another person can repeat.

Save evidence at the right level

More evidence is not always better. A full browser recording may expose private information and make a simple result hard to review.

Capture the smallest useful proof:

  • a public URL and final screenshot
  • a short list of measured values
  • the exact error message that triggered a repair
  • a link check report
  • a before-and-after block count
  • a dated source list

Redact account details, private email addresses, referral dashboards, and tokens. Public proof should not create a security or privacy problem.

Distinguish prepared work from public work

This is one of the most important lines in a browser-based workflow.

A local draft, a generated WordPress block file, and a publication plan are prepared artifacts. They are not proof that a post is live.

Use clear status language:

  • Drafted locally
  • Validated locally
  • Scheduled in WordPress
  • Published and publicly verified

Do not skip from “ready” to “published” without checking the public page.

Use a compact workflow record

A practical record can fit on one page:

  1. Outcome: What should be true when the work is complete?
  2. Scope: Which pages, files, tools, and links are included?
  3. Preserve: What must not change?
  4. Sources: Which current references support factual claims?
  5. Decisions: Why were key options selected?
  6. Execution: What was changed?
  7. Verification: Which checks passed or failed?
  8. Status: Is the work drafted, scheduled, or publicly verified?
  9. Next review: When should links or claims be checked again?

Documentation supports better judgment

The purpose of documentation is not to make a simple workflow feel complicated. It is to keep important context from disappearing.

When a process records its outcome, constraints, decisions, and verification, another person can review it without guessing. The original editor can also return weeks later and understand why the system looks the way it does.

That is what makes an AI-assisted workflow dependable: not the prompt alone, but the human decisions and visible evidence around it.

Use this workflow record as the editorial companion to any AI-assisted draft before it goes live.