# One finding, from observed fact to verified fix

> Three acts, using the product’s own components at every stage.

Source: https://citetune.com/how-it-works

## Act one — evidence

A finding opens with what we literally saw: status codes, headers, byte counts and the user agent that produced them, quoted rather than summarised.

The inferred mechanism sits in a separate, differently coloured band, and carries the line that would disprove it.

## Act two — a fix you review

The proposed change is a diff with a safety tier, the preconditions we checked before drafting it, and the exact revert that undoes it.

It is a pull request against your repository. We never hold a write credential to your live site.

## Act three — proof

After the merge we re-run the identical check and report whether the defect still reproduces, with the date and the rule id.

Any change in AI visibility is reported separately, with its completion rate, and we do not draw a causal arrow between the two.

## Steps

1. **Get the evidence** — Run a bounded, same-site crawl and collect the observed facts for each of the sixteen deterministic rules.
2. **Review the safe fix** — Read the proposed diff, its safety tier, its preconditions and its rollback plan, then merge the pull request yourself.
3. **Verify the result** — Re-run the same check and confirm the defect no longer reproduces, with any visibility change reported separately.