The problem with document naming on construction projects
ISO 19650 requires every document in a Common Data Environment (CDE) to follow a strict naming convention. This isn't a suggestion — it's the mechanism that makes documents findable, sortable, and auditable across the lifecycle of a built asset. When naming breaks down, everything downstream breaks with it: automated workflows can't parse filenames, handover packages get rejected, and audit trails become unreliable.
The reality on most projects is that naming conventions are defined in a BIM Execution Plan, distributed as a PDF, and then... hoped for. Dozens of contributors upload files across months or years. Subcontractors who joined mid-project may never have seen the naming guide. Even experienced team members make mistakes — a dash instead of an underscore, a missing status code, fields in the wrong order.
The cost of getting naming wrong
Handover rejection by the appointing party. Rework to rename and re-upload hundreds of files. Failed compliance audits. On large projects, a single naming convention failure discovered at handover can mean weeks of remediation work and significant cost.
What ISO 19650 naming actually looks like
ISO 19650 doesn't prescribe a single naming format, but it defines the fields that must be present. The most widely adopted pattern in the UK (aligned with BS EN ISO 19650) uses seven fields separated by a consistent delimiter:
Standard naming pattern
Project
Project identifier
Originator
Organization code
Zone
Spatial zone / area
Level
Floor or level ref
Type
Document type code
Role
Discipline role code
Number
Sequential number
Here are some examples of filenames that follow this pattern, and common mistakes that break it:
| Filename | Valid? | Issue |
|---|---|---|
| PRJ-ARC-ZZ-01-DR-A-0001.pdf | Valid | -- |
| PRJ-STR-B1-03-SP-S-0042.dwg | Valid | -- |
| PRJ_ARC_ZZ_01_DR_A_0001.pdf | Invalid | Wrong separator (underscores instead of dashes) |
| PRJ-ARC-01-DR-A-0001.pdf | Invalid | Missing Zone field (only 6 fields) |
| ARC-PRJ-ZZ-01-DR-A-0001.pdf | Invalid | Fields in wrong order (Originator before Project) |
| Foundation Plan Rev C.pdf | Invalid | No convention at all (descriptive name) |
Approach 1: Manual spot-checks
The most common approach on projects today. A document controller opens Forma, scrolls through folders, and visually checks each filename against the naming guide PDF. They might keep a spreadsheet to track violations and send emails to originators asking for corrections.
At roughly 3 minutes per file (open folder, read filename, compare against convention, log the result, move on), a 500-file project check takes about 25 hours. And that's just the check — it doesn't include the time to chase corrections. Most document controllers do this monthly at best, which means non-compliant files can sit in the CDE for weeks before anyone notices.
Verdict: doesn't scale
Manual checks work on small projects with fewer than 50 files. Beyond that, the time cost is prohibitive and the coverage is always incomplete. You're sampling, not checking.
Approach 2: Regex in a script
The developer approach. Write a Python or PowerShell script that connects to the Forma API, pulls a file listing, and runs each filename against a regular expression. Non-matching files get logged to a CSV. Fast, thorough, and repeatable.
Example regex for the 7-field pattern
This works, and for teams with developer resources it's a legitimate option. But there are practical problems:
Requires a developer to write, maintain, and run the script. When the naming convention changes, the developer has to update the regex.
No user interface — results are a raw CSV or terminal output. Non-technical team members can't run checks or interpret results.
No scheduling — someone has to remember to run it. No dashboards, no trend tracking, no alerts.
One convention for everything — real projects often need different naming rules for different folders (drawings vs. specifications vs. reports). A script handles this poorly.
Verdict: effective but high-maintenance
If you have a developer on the team and simple naming rules, a script is a solid option. But it creates a dependency on one person, and it won't grow with the project's complexity.
Approach 3: Automated naming checks with Foreman
Foreman includes built-in ISO 19650 naming convention rule sets that run directly against your Forma project files. No developer required. The system ships with pre-configured rule sets for common standards, and includes an AI regex builder — paste a sample filename and Foreman generates the pattern for you.
The process takes three steps:
Define your naming rules
Choose a built-in ISO 19650 rule set or create your own. Use the AI regex builder to generate patterns from sample filenames — paste PRJ-ARC-ZZ-01-DR-A-0001.pdf and Foreman produces the matching regex. Assign different rule sets to different folders if your project uses different conventions for drawings, specifications, and reports.
Run the check
Select the folders to check and run. Foreman scans every file, evaluates each filename against the assigned rules, and produces a result set. Files are flagged as passing or failing, with specific details on what's wrong (missing field, wrong separator, invalid code).
Schedule and report
Set up a scheduled check to run daily, weekly, or on a custom cron. Results appear on the dashboard with trend charts, and you can export PDF or XLSX reports for stakeholders. Violations can be pushed directly to Forma Issues for tracking.
Per-folder rules
Different naming conventions for drawings, specs, and reports
Scheduled runs
Daily, weekly, or custom cron schedule with email alerts
Dashboard + reports
Trend charts, PDF reports, and CSV/XLSX export
AI regex builder
Don't know regex? No problem. Paste a valid filename like PRJ-ARC-ZZ-01-DR-A-0001.pdf and Foreman generates the naming convention pattern automatically. You can then fine-tune the allowed values for each field.
Comparison: three approaches side by side
| Capability | Manual | Script | Foreman |
|---|---|---|---|
| Time per check cycle (500 files) | ~25 hours | ~5 minutes | ~2 minutes |
| Requires developer | No | Yes | No |
| Scheduled / automated runs | With extra setup | ||
| PDF / XLSX reports | CSV only | ||
| Per-folder rule sets | |||
| Dashboard with trends |
Beyond naming patterns: segment-level and cross-field validation
Regex validates that a filename looks right. But does segment 6 contain a real ISO 19650 discipline code? Is the originator in segment 2 on the project's approved list? These questions need a different kind of rule.
Foreman now includes List Validation rules that check individual filename segments against reusable validation lists — with built-in ISO 19650 discipline, form, and suitability codes ready to use out of the box. Numeric Range rules validate sheet numbers are within bounds. And Segment Consistency rules catch invalid combinations like a structural drawing uploaded by an architectural originator.
Read more: How to Validate ISO 19650 Naming Segments and How to Set Up Conditional Cross-Field Rules.
Key takeaway
For projects with fewer than 50 documents, manual checks are manageable. A document controller can visually verify naming conventions without tooling. Beyond that threshold, you need automation.
The question is whether that automation requires a developer on your team. If you have one, a script works. If you don't — or if you need per-folder rules, scheduled runs, trend dashboards, and exportable reports — Foreman handles it without writing a line of code.