AI for Auditing Filename Collisions

As of 2026-10-19 · the AZET team. We wrote this practical exercise for fun and reference. The folder and filenames below are invented to make the review steps visible.

Two photographs arrive from different cameras. Both are called image01.jpg, and both belong to the same weekend project. A request to make every filename shorter sounds harmless until the proposed names become identical. The useful question is whether the mapping preserves a separate destination for every source.

A text assistant can be asked to draft that mapping. Its response is still a proposal. This guide walks through a small collision audit that you can inspect before any file changes. You do not need to upload the photographs, give an assistant folder access, or start with your entire archive.

Write down what a filename must preserve

Suppose your illustrative project contains photographs, a contact sheet, and a cover draft. Start by deciding which distinctions matter to you. A camera label might be useful; a long download suffix might not. Keep the original extension visible so that a photograph and a layout document do not look interchangeable.

Make the requested format explicit. For this exercise, use a project word, a source label, and a two-digit sequence. The exact convention is less important than being able to explain it. If you cannot tell whether the sequence resets for each source, the assistant has to guess.

Include the original folder as part of each source identifier. Two matching basenames in separate folders are two inputs. A flattened list that drops the folder names hides the very collision you want to examine.

Build a proposal with no file operations

Here is a hypothetical review table. The last column is a human review note rather than an instruction to execute anything.

Original location	Proposed name	Review note
camera-a/image01.jpg	weekend-a-01.jpg	Source label retained
camera-b/image01.jpg	weekend-b-01.jpg	Distinct from camera A
layouts/cover-final.pdf	weekend-cover.pdf	Version policy unresolved
layouts/cover-final-2.pdf	weekend-cover.pdf	Collision with previous row

The final pair is a problem even though the proposed name reads well. Keep both rows. Removing one from the table would turn a visible conflict into an invisible missing file.

Ask for an unresolved status when the naming rule runs out of information. Do not let the model invent a creation date or infer the newest version from a word like final. Those details require evidence from your files or your own records.

Use a prompt that produces reviewable evidence

Try this request with a small, non-sensitive list:

Draft a filename mapping from the source paths I provide. Do not give commands or claim to rename anything. Keep one row per source. Preserve extensions. Flag every repeated destination, missing source label, and ambiguous version. When the rules cannot determine a unique name, write unresolved and explain which decision is missing. Return original path, proposed name, status, and reason.

Then supply the naming rule and the source list. Ask the assistant to repeat the number of input rows and output rows. Count them yourself too. A tidy table can still omit an awkward record, so visual neatness is not your acceptance test.

For a longer list, work on a bounded group first. Review how the rule behaves with spaces, punctuation, and very long original names. Treat these as samples you chose, not proof that every naming environment behaves identically.

Inspect the destination as a separate list

Read only the proposed names in a second pass. This makes duplicates easier to see without the original paths competing for attention. Check whether the destination folder already contains a file with any proposed name. A mapping can be unique within its own rows and still conflict with something outside the batch.

Also consider the environment where the names will be used. If differences in capitalization are your only distinction, test that situation in a disposable copy on the actual destination system. Avoid asking a language model to certify filesystem behavior from the names alone.

Resolve each flagged case explicitly. You might add a source label, retain a version suffix, or leave a file unchanged. Record the reason beside the decision so another person can reconstruct it later.

Keep a small undo record

Before applying any approved changes yourself, keep a copy of the original-to-new mapping and preserve the originals in a reversible way. Test a few duplicate files in a temporary folder first. Check that each expected file remains present and opens as intended.

The mapping is also an undo reference. Its usefulness depends on recording the exact names actually used. If you change the convention halfway through, update the record rather than leaving a clean-looking plan that no longer describes the result.

FAQ

Should the assistant choose my naming convention?

It can offer alternatives, but provide the distinctions your project needs. Compare two short proposals against the same sample files. Pick the one you can read and apply consistently, including the awkward cases.

Does a unique destination list prove the rename is safe?

No. Check the destination folder, permissions, application dependencies, and your recovery copy separately. This exercise concerns proposed names; it does not inspect your filesystem or establish that a tool performed the changes correctly.

What if I have thousands of files?

Start with a representative sample and validate the rule. Larger batches benefit from an appropriate local checking tool and a saved mapping. Do not interpret a fluent response containing many rows as evidence that every row was preserved.

A bounded role for an assistant

This is a general planning exercise, not a documented AZET file-management feature. Our October 3, 2026 maker introduction describes an AI assistant and an early-access waitlist; that dated source does not establish live availability today. For the AZET waitlist, visit azet.io.