Facts, inferences, and unknowns: keep them separate in AI delivery reports

“The main content is already in the HTML, so the website is faster and its SEO is better.”

This sentence joins conclusions with different levels of support. You can check the first part by reading the output files. The second part still needs evidence about speed and search performance. Even if the first part is true, that does not make the second part verified.

When working with AI, delivery reports are worth reading sentence by sentence. Instead of asking only whether the tests passed, a more useful question is: Does this sentence describe an actual observation, offer a judgment, or present an unknown outcome as something that has already happened?

Facts need an identifiable observation

When this site was refactored from Vue to native Astro, one explicit requirement was that opening a URL directly should return HTML containing that page’s main content.

To support that claim, you can read the built HTML and check that the body content and title are present. Finding a component in the source code is not enough. That observation supports the statement that this output file contains the body content. To say that every page contains it, you also need to establish which pages the check covered.

A fact needs a scope as well as a source. One page, this build, the local environment, and the production server are different things to observe. Remove the scope, and an accurate report can become an overpromise.

Likewise, finding a component file confirms only that the file exists. To say it was a feature of the old site, you also need evidence of where it was accessed and how it was actually used. During this site’s refactor, a technology filter was added. A later check showed that the old site had kept a related component, but its pages did not reference it. The feature that needed to be preserved was switching between project categories.

You do not need measurements to spot this kind of mistake. Separating “the file exists” from “the feature was available” reveals the missing evidence.

Keep inferences, but explain how you reached them

“The website is mainly for reading, so generating the body content at build time fits the content goals of this refactor.” This is an architectural judgment.

It has a basis: the site needs to present an introduction, projects, and articles, and the requirements explicitly call for readable initial HTML. Those conditions support choosing static content. They do not make that choice the right answer for every website.

An inference is not another word for an unreliable claim. Design and development require judgment. The question is whether you explain the basis for it and the conditions that would call for reassessment.

You could describe an inference in a delivery report like this:

For this refactor, readers should be able to open a URL and read the body content directly, so we generate the page content at build time. This fits the current content requirements. If we later add extensive real-time interactions behind a login, we will still need to reassess how to implement those features.

This is an example of how to explain a decision, not a new performance test result. It preserves the reason for the choice and makes its assumptions clear.

Unknowns should point to the next question

Not measuring load speed does not mean the website must be slow. Having no search traffic data does not mean the architecture has no value. It means neither outcome can be reported as an achievement of this work.

Unknowns can be specific:

Question we cannot yet answer	Evidence we could add if an answer is needed
Is the new version faster than the old one?	Measure both versions under comparable conditions, specifying the pages, devices, and network environment.
Is it comfortable to read on a phone?	Have the site owner read it and assess the width, paragraph rhythm, and content order.
Does the production server return the right pages?	Request the actual URLs after deployment and check the status, body content, and resources.
Do the notes help readers understand the projects better?	Gather reader feedback or observations suited to that question.

These are directions for further verification, not measurements this site has already completed.

“Not every situation has been tested” is too broad to help a reader decide what to do next. If you only checked local output, say directly that the production server has not been checked. If content and technical checks are complete but someone still needs to confirm the visual presentation, list that as pending acceptance. The closer a limitation is to the question at hand, the easier it is to plan the work.

Split mixed claims so each can be checked

The following sentence is a deliberately constructed example of a poor delivery report, not actual tool output:

The draft has been integrated into the article system and the checks have passed, so the article can go public and readers should find the website easier to understand.

It needs to be split into several independent questions.

Whether the draft has been integrated depends on the content source and local preview. A claim that checks passed needs the checks and their results. Making the article public requires the site owner’s decision about the content and what may be made public. None of those three can answer whether readers find the site easier to understand.

A clearer explanation would be:

The article has been integrated into the local preview and remains a draft. Engineering check results are listed separately. The site owner will confirm the content, what may be made public, and the reading layout. This article includes no measurement of reader understanding, so it does not report an improvement in that area.

You do not have to use this format every time, but each sentence should hold up on its own. A connecting word cannot fill a gap in the evidence.

When the evidence changes, correct the original conclusion first

Suppose a delivery report first says that no drafts are included in the production output, but a draft URL is later found. Adding “there may still be exceptions” at the end is not enough. You need to investigate whether old build files were not fully cleared, the source state was read incorrectly, or the production query really failed to filter out drafts.

This is a hypothetical troubleshooting scenario, not a newly discovered incident on this site. The point is the order of correction: first withdraw the conclusion that no longer holds, then find the cause, and read the relevant output again after fixing it. You cannot keep a “completed” heading and leave readers to infer from a footnote that the work is not actually complete.

Before delivery, question one of the strongest claims

Not every collaboration needs to become a word-by-word trial. Start with a statement that affects a decision, such as “everything is complete,” “nothing leaked,” “faster,” or “published,” and ask for its evidence and scope.

If you can identify an observation, state it as a fact within that observation’s scope. If the claim is a choice derived from requirements, explain the assumptions behind the inference. If you have no data, leave a specific unknown and a direction for verification. Keeping these separate lets people decide whether to adopt the judgment, add a check, or hold off on making something public.

Scope of this record

This article draws on this site’s refactor, checks of evidence for existing features, and content publishing rules to explain how to assess delivery reports. The opening quotation, poor delivery example, and troubleshooting scenario are illustrative. They are not original chat excerpts, test records, or new measurements. This article does not claim that the method has improved development efficiency, search performance, or reader understanding.