Before the AI edits: find the live truth

AI agents are very good at acting on the context they receive. That strength becomes a liability when the context is a stale checkout, a detached branch, an exported build, or a generated file that will be overwritten five minutes later.

The first job is therefore not editing. It is orientation: establish what is live, identify the artifact serving it, and trace that artifact back to its owner. The goal is a short chain of evidence—not a guess based on a familiar folder name.

§1Treat every local copy as a claim

A local project may be correct, but its existence does not prove that it owns production. It might be an earlier clone, a preview experiment, a build output copied from somewhere else, or a branch that never shipped.

This changes the direction of investigation. Instead of moving from local files outward and hoping they match, move from the public result inward until the editable owner is unambiguous.

§2Begin with observable public reality

Open the exact public URL involved in the requested change. Record what is visibly present and collect a small fingerprint that a deploy or source tree can reproduce:

• the final URL after redirects;
• the page title and one distinctive sentence;
• the names and version strings of loaded CSS or JavaScript assets;
• a response header, build marker, or stable file hash when available;
• the behaviour that the change is meant to preserve or improve.

One fingerprint can be misleading. A title may be shared by many copies. A bundle name may survive several releases. Two or three independent markers create a much stronger match.

§3Trace the source-of-truth map

Move through the chain in this order. Each stage answers one question and produces the clue needed for the next.

§4Use an evidence ladder, not one reassuring clue

The rows are related, but they are not interchangeable. A deploy directory can prove what was published while still being the wrong place to edit. A current branch can be editable while still not being the branch that owns the live release.

↑ contents

§5Separate editable source from generated output

Many websites contain files that look hand-editable but are produced by another layer: a template, a data file, a content collection, or a build script. Editing the output can appear to work locally and then vanish on the next build.

Before changing a file, inspect the build path:

1. Find the command that creates the publish directory.
2. Check whether the target file exists before the build or appears during it.
3. Search for a distinctive line from the output across templates, data, and scripts.
4. Make a harmless source change in a disposable copy and confirm the expected output changes.
5. Record the source-to-output relationship for the next run.

§6Stop when the layers disagree

A mismatch is not noise to work around. It is the most valuable discovery in the orientation pass. Common examples include:

• the public page loads an asset version that no local build produces;
• the latest-looking branch does not contain the active deploy revision;
• the deploy artifact contains a page that the repository cannot build;
• the apparent source file is regenerated from a different template or data set;
• two projects share the same domain history, but only one owns the current release.

At that point, pause the edit and explain the disagreement in one sentence. Resolve ownership first. A fast change in the wrong tree creates more uncertainty than it removes.

§7Leave a compact orientation packet

Once the chain is established, save only what another person or agent needs to resume safely. Keep sensitive infrastructure details out of public artifacts; the pattern works with neutral identifiers.

source-of-truth packet

PUBLIC RESULT
URL: [exact route]
Fingerprint: [two or three observable markers]

ACTIVE ARTIFACT
Deploy: [immutable identifier]
Built from: [revision identifier]

EDITABLE OWNER
Branch: [owning branch]
Source: [source file or data entry]
Build path: [source → generator → publish output]

SAFE NEXT ACTION
[smallest change that should alter the public fingerprint]

STOP IF
[the evidence that would disprove this ownership chain]

The stop condition matters. It makes the packet falsifiable: a future agent knows exactly what new evidence should trigger re-orientation instead of blindly following an old note.

§8Confirm the chain with one reversible change

Before a large edit, change a low-risk marker in a preview or disposable build. Confirm that the expected source produces the expected artifact and that the artifact produces the expected public behaviour. Then revert the marker and make the real change.

This is the bridge between orientation and verification: first prove that you are changing the right system, then prove that the system changed in the right way. When the work becomes public, use a deliberate privacy boundary. When it becomes a new page, carry the result through the publishing workflow.