How to Validate ISO 19650 Naming Segments in Autodesk Forma

Why regex is necessary but not sufficient

If you've read the guide on automating naming convention checks, you know how to use a regex-based naming convention rule to validate the overall structure of an ISO 19650 filename. A pattern like ^[A-Z]{3}-[A-Z]{3}-[A-Z0-9]{2}-[A-Z0-9]{2,3}-[A-Z]{2}-[A-Z]{1,2}-\d{4}\.[a-z]+$ will catch filenames that don't match the expected shape — wrong number of segments, missing delimiters, letters where numbers should be.

But regex operates on character patterns, not domain values. Consider the filename PRJ-XYZ-ZZ-01-DR-A-0001.pdf. The regex above would pass it — the format is correct. But is "XYZ" a valid originator code on this project? Is "ZZ" a recognized zone? Is "A" the right discipline code for architectural drawings? Regex can't answer these questions. It validates syntax, not semantics.

This is where list validation and numeric range rules come in. They let you validate the actual values within individual segments of the filename, using project-specific allowed values. Combined with a naming convention rule for overall format, you get complete validation — both structure and content.

The ISO 19650 naming structure, segment by segment

Before configuring segment-level validation, it helps to map out the standard naming convention and understand what each segment represents. The UK National Annex to BS EN ISO 19650-2 defines the following structure:

Each segment has a different validation requirement. The project code is typically a single fixed value. The originator, zone, form, and discipline codes are drawn from finite lists defined in the BIM Execution Plan. The sheet number is a sequential integer within a defined range. List validation handles the first group; numeric range handles the last.

Validating individual segments with list validation

A list validation rule extracts a specific segment from the filename and checks whether its value appears in an approved list. You configure it by specifying the segment position (which field in the delimited filename), the delimiter character (usually a dash), and the validation list to check against.

Originator codes

The originator segment (position 2) identifies the organization that produced the document. On a typical project, this list might include 5-15 codes — one per design team, subcontractor, or consultant. For example: ACE (architect), BKR (structural engineer), CRN (MEP consultant), DLT (civil engineer), ELM (landscape architect). Create a validation list with these codes and a list validation rule targeting segment 2.

Discipline codes

The discipline segment (position 6 in the standard layout) uses single or double-letter codes defined in BS EN ISO 19650. Common values include A (architecture), S (structural), M (mechanical), E (electrical), C (civil), L (landscape), and B (building services). Your project may use a subset of these, or may define additional project-specific codes. Create a validation list with only the codes relevant to your project, and a list validation rule targeting the discipline segment.

Form codes

The form segment (position 5) describes the type of information container. Standard values include DR (drawing), SP (specification), SH (schedule), RP (report), MO (model), and VS (visualization). This is another segment where the allowed values are finite and project-specific. A list validation rule catches files labelled with non-standard form codes — for example, "DW" instead of "DR" for drawings, which is a common mistake from teams accustomed to older conventions.

Built-in ISO 19650 validation lists

To save you from manually typing out standard ISO 19650 code sets, Foreman ships with five built-in validation lists based on the BS EN ISO 19650 UK National Annex:

These lists are read-only — you can't modify the standard values. However, you can clone any built-in list to create an editable copy. This is the recommended approach when your project uses a subset of the standard codes or adds project-specific extensions. Clone the list, remove the codes that don't apply, add any custom ones, and rename it to reflect your project. The cloned list is then available for use in your rules.

Originator codes are not included in the built-in lists because they are always project-specific. You will need to create your own originator list for each project, populated with the codes assigned in your BIM Execution Plan or Responsibility Matrix.

Sheet number validation with numeric range

The final segment in the ISO 19650 naming convention is the document number — typically a four-digit sequential number like 0001, 0002, 0003. This segment doesn't map well to a validation list (you'd need 9,999 entries). Instead, use a numeric range rule.

A numeric range rule extracts the value at a specified segment position, parses it as an integer, and checks whether it falls within the defined minimum and maximum. For standard sheet numbering, set the minimum to 1 and the maximum to 9999. The rule also validates zero-padding — if you specify a pad width of 4, the value "0042" passes but "42" fails, even though both represent the same number.

This catches several common errors. Files numbered "0000" (zero is typically not a valid sheet number). Files with five-digit numbers that exceed the project's numbering scheme. Files where the number segment contains letters — for example, "001A" which might be a sub-sheet indicator that doesn't conform to the standard. And files where padding has been lost, like "42.pdf" instead of "0042.pdf."

Combining segment validation with naming convention rules

The most robust approach is to use all three rule types together in a single rule set. The naming convention rule (regex) validates the overall structure — correct number of segments, correct delimiter, correct character types in each position. The list validation rules validate the semantic content of each coded segment — are the originator, discipline, form, and zone values drawn from the project's approved lists? The numeric range rule validates the sheet number — is it within bounds and correctly padded?

When a file fails the naming convention rule, it means the format is wrong — the file probably needs to be completely renamed. When a file passes the naming convention rule but fails a list validation rule, it means the format is correct but one specific value is invalid — the fix is targeted. This distinction is important for the person doing the remediation because it tells them exactly what's wrong, not just "the filename doesn't match."

This layered approach means that when a file is flagged, the violation message tells you exactly which segment is wrong and what the allowed values are. Instead of "filename does not match pattern," you see "originator code 'FRN' is not in the approved originator list (ACE, BKR, CRN, DLT, ELM)." That's actionable. The person fixing the file knows exactly which three characters need to change and what the valid options are.