Exact filename vs document-number matching

Both approaches compare register data with filenames. They differ in how much of the filename must agree and therefore in the conclusions you can draw from a match.

Exact filename matching

Exact matching compares the complete expected filename from the register with the scanned filename. A case-insensitive implementation may treat DP-FIR-006-C03.PDF and dp-fir-006-c03.pdf as the same name while still requiring every other character to agree.

Use it when

• The register contains an approved expected-filename field.
• Filename composition—including revision or status—is governed by a convention.
• A descriptive suffix is expected to remain stable.
• You need to expose even small naming differences.

Strength

The rule is easy to explain and audit: one complete expected string is compared with one actual filename. It detects extra or missing characters that token matching would intentionally ignore.

Limitation

A document can have the correct filename but incorrect content. The rule also produces a missing and unexpected pair when a harmless descriptive suffix changes, even if the document identity is otherwise obvious.

Document number in filename

Token-aware matching finds a mapped document number within a filename as complete tokens separated by recognised punctuation such as hyphens, underscores, dots or spaces. It should not match a short identifier merely because the same characters appear inside a longer unrelated number.

Use it when

• The document number is controlled but descriptive text varies.
• Different systems append their own filename suffixes.
• The register does not contain a reliable complete-filename field.
• Your first question is whether each document identity appears in the package.

Strength

The rule tolerates descriptive variation while preserving token boundaries. It is more useful than substring searching and less brittle than a complete-filename comparison.

Limitation

It does not validate revision. It may also find multiple candidates when several revisions or copies of one document number exist. That ambiguity is useful evidence, but it requires human review.

How to decide

1. Ask which register field is authoritative and consistently populated.
2. Confirm whether revision must be checked at filename level.
3. Test the rule against known duplicates and naming variations.
4. Document the selected rule in the handover evidence.

If the complete expected filename is controlled, start with Exact Filename. If it is not, do not fabricate filenames from several fields unless that composition is formally defined. Use document-number matching and perform revision verification separately.

What both rules can report

A deterministic comparison can classify each relationship as Ready, Missing, Unexpected or Ambiguous. The Ambiguous class is especially important: selecting the first candidate silently would hide duplicate copies or mixed revisions.

What neither rule can prove

• That a drawing or document opens successfully.
• That the title block matches the filename.
• That the technical content is correct.
• That approval signatures or status codes are valid.
• That the recipient has accepted the handover.

Those conclusions require additional controls. A filename preflight is one evidence-producing step inside a broader release process.

See the full document handover checklist or inspect real screenshots of both modes in Deliverable Preflight.