From a repair statement to a comparable recheck
Use a before-and-after example to distinguish an asserted repair, a comparable observation and an inconclusive result.
Your coding assistant says it added the missing Strict-Transport-Security header, also called HSTS. The HSTS specification describes how it asks browsers to remember an HTTPS policy. The configuration diff looks right. What do you know now? You have a proposed change and a statement about it. You do not yet have a new observation of the response your website delivers. A comparable recheck answers that later, narrower question.
Consider a synthetic homepage at demo.example. An earlier inspection received a response without the HTTPS-policy header. Someone then edited the configuration. The table follows that sequence and includes an alternative where the later inspection cannot obtain the response it needs. It is teaching material, not a report export or a customer result.
Follow the evidence through the change
| Stage | Evidence in this example | What it supports |
|---|---|---|
| Earlier response | The inspected homepage response lacks the HTTPS-policy header | The header was not observed in that response then |
| Coding assistant's statement | It edited the header configuration | A repair is asserted; there is no new response observation yet |
| Later response | The later inspection checks the same homepage for the same header, and the required observation completes | The header is now present in the inspected response; the earlier absence is no longer observed within this scope. |
| Alternative later attempt | The required response could not be inspected | Inconclusive; the edit does not supply the missing evidence |
The third row needs every part of its description. A later observation must concern the relevant resource, and the check must have the evidence it needs. Simply failing to reproduce a finding is not enough when collection itself failed. The fourth row makes that distinction visible instead of letting an unavailable response look like progress.
A repair note remains useful. It can identify the intended change and help someone investigate a mismatch. Keep it alongside the observations rather than asking it to stand in for one. A tool's confident wording cannot fill a gap in collected evidence.
An edit and a delivered response are different facts
The assistant may have changed the right file, but the change still has to reach the place that serves the response. A diff does not establish which configuration the running deployment uses. Likewise, a deployment statement does not describe every response someone will receive afterward.
Caching is one possible reason to inspect that relationship carefully. HTTP Caching, section 4 describes conditions under which stored responses can be reused. It supplies background for the distinction; it is not evidence that a cache caused a mismatch in your application. Establish that cause separately if it matters to your repair.
For this example, the useful question is not whether the assistant sounded certain. It is whether the later inspection obtained the response needed to test the earlier observation. Keep the earlier report intact so you can still see what was observed, where and on what basis.
Check that the comparison answers the same question
Before interpreting a difference, check the resource and the method used to inspect it. Then check the rule or policy basis behind the result. A change in the assessment can alter its interpretation without representing a change in the website. Similar-looking titles do not establish that two findings were evaluated in the same way.
In our example, both observations concern the same homepage and the same header-presence question. If the later attempt reaches only a different resource or lacks the necessary comparison details, do not quietly substitute it for the earlier inspection. State what is missing before drawing a conclusion.
SecurityFuse's comparison distinguishes newly observed, still observed, no longer observed and inconclusive results. An absent finding supports "no longer observed" only when the recheck contains the required evidence. Missing evidence can leave the result inconclusive. Those labels describe the comparison that the evidence supports; they do not approve the deployment or certify the rest of the application.
Read “no longer observed” literally
When the later response returns the header on a comparable basis, the earlier absence is no longer observed in that scope. That does not answer every question about the setting. The HSTS specification, sections 6.1 and 8 defines the policy's duration, optional subdomain scope and browser processing. Seeing the field is different from deciding whether its policy fits the website.
Keep the outcome connected to the original question. If you need to decide which configuration change is appropriate, A security header finding is a starting point develops a bounded request for that work. Do not use a changed comparison label to skip reviewing the change itself.
For an inconclusive result, identify the missing basis before asking for another attempt. Repeating the assistant's repair statement will not obtain a missing response or restore absent comparison details. What a website configuration scan can—and cannot—tell you explains why an unanswered question must remain visible.
SecurityFuse's public sample includes a recorded recheck of our own test site. SecurityFuse is available by invitation. Hosted website scanning is not currently enabled. The sample does not offer a hosted recheck entry point. The synthetic table here teaches the decision to make: a repair assertion records intent, while a comparable later observation can support a scoped statement about what changed.
Sources
- HTTP Caching — RFC 9111 · Section 4: constructing responses from caches · Reviewed 2026-10-31
- HTTP Strict Transport Security — RFC 6797 · Sections 6.1 and 8: directives and browser processing · Reviewed 2026-10-31