Definition
A finding needs a specific retest after the merchant changes the source page, markup, feed, policy, or checkout path. Post-fix validation is therefore the deployment-like re-verification performed after a remediation to prove the original issue no longer reproduces and that adjacent behaviors have not regressed across relevant channels, models, and protocols.
StoreSteady treats post-fix validation as a reference term because Not replay-tested: Fix deployed without replaying the original failing scenario.
Why it matters
- Not replay-tested changes what a crawler, shopping channel, or AI assistant can safely infer about the merchant surface.
- Without a named category, operators tend to treat post-fix validation as generic AI noise instead of a reproducible finding with evidence and a validation path.
Evidence sources
- scenario replay against the original failing case; adjacent-flow regression checks; version-aware comparison (model version, page version, protocol version); recurrence-monitoring window after release.
How StoreSteady detects it
Audit fix records for: attached replay evidence, adjacent-flow regression results, version metadata (model, page, protocol), and a scheduled `recurrenceCheckAt`.
False positive risks
- Marking a fix complete because the developer ran the code locally and "it works on my machine."
- Verifying only the target scenario without checking adjacent flows.
How to fix it
- Identify the merchant-controlled source that creates the post-fix validation signal.
- Reconcile visible copy, machine-readable data, policy text, feed state, and checkout behavior where the term applies.
- Keep the fix high-level in public docs; detailed remediation belongs inside paid scan workflows.
How to validate it
Rerun the same evidence capture used for detection. The finding is validated only when the original post-fix validation signal no longer reproduces and adjacent source surfaces still agree.
Example finding
Not replay-tested
Observed: A scanner detected `TRU-002` (price mismatch). After the merchant fixed the feed rule, the scanner re-ran the exact same comparison at the same surfaces and confirmed parity. A recurrence check is scheduled in 48 hours.
Likely impact: Not replay-tested: Fix deployed without replaying the original failing scenario.
Probable fix location: Post-fix evidence record
Related StoreSteady issue codes
| Code | Title | Scanner mapping |
|---|---|---|
| VAL-001 | Fix not replay-tested | Planned detector |
| VAL-002 | Fix regressed adjacent flow | Planned detector |
| VAL-003 | No version-aware proof attached | Planned detector |
| VAL-004 | No recurrence-monitoring window | Planned detector |
Related standards
See also
Sources
Run a scan against this category
StoreSteady scans public commerce evidence and maps findings back to documented taxonomy terms.
Run a free scan