Compare a trusted baseline with the candidate you plan to release
File Set Change Check is useful when you have an earlier file set that represents the accepted state and a newer candidate that may contain additions, removals or changed files. Typical examples include website assets, delivery folders, exported media packs and other release bundles.
Use a baseline you actually trust
The result is only as meaningful as the two sets you select. TaskThimble can show which paths are added, removed or changed between them; it cannot decide whether every change is desirable or expected.
Changed, added and removed are different release questions
An added file may be intentional, a removed file may be a regression, and a changed file may simply contain an approved update. Keeping these states separate makes the review more useful than a generic “different” flag.
Verified versus unverified
Where browser fingerprinting succeeds, same-path files can be compared by content. Anything that cannot be content-verified stays visible for review instead of being silently treated as unchanged. That distinction matters when the file name stayed the same but the contents may not have.
Learn how to interpret a file-set diff →
Re-run before the final handoff
Review the candidate, correct unintended changes and run the comparison again. If the final package also has explicit naming, format, size or count requirements, use File Readiness Check as a separate gate instead of treating the change comparison as a complete release approval.