The problem that single-field validation cannot solve
You have set up list validation rules for your ISO 19650 naming segments. The originator code is checked against the approved list. The discipline code is checked against the standard set. The form code is validated. Every segment, individually, contains a valid value. The naming convention regex passes too. Everything looks correct.
Then you notice that the file
PRJ-BKR-ZZ-01-DR-A-0015.pdf
has originator code BKR (your structural engineer) and discipline code A (architecture). BKR is a
valid originator. A is a valid discipline. But BKR producing architecture drawings? That is almost
certainly an error. The structural engineer should be producing discipline S documents, not
discipline A.
This is a cross-field consistency problem. Each field is valid in isolation, but the combination of values across two fields violates a business rule. Regex cannot express this constraint. A naming convention pattern treats the filename as a single string. List validation checks one segment at a time. Neither can say "if segment 2 is BKR, then segment 6 must be S."
How these errors happen
The most common cause is copy-and-rename workflows. A team member copies an existing file to use as a template, updates most of the segments, but forgets to change one. The filename looks right at a glance — all the segments are valid codes — but the relationship between segments is broken. On large projects with hundreds of files, these errors accumulate undetected until an audit.
What segment consistency rules do
A segment consistency rule defines a conditional relationship between two segments in the filename. The logic is: "If Source A (at position X) equals a specific value, then Source B (at position Y) must be one of [allowed values]." You define one or more condition mappings, each linking a value in Source A to a set of permitted values in Source B.
When the rule runs, it extracts the value at position X, looks up the condition mapping for that value, and then checks whether the value at position Y appears in the permitted set. If it does, the file passes. If it doesn't, the file is flagged with a violation that names both segments and both values — for example, "Originator BKR (segment 2) requires discipline to be one of [S], but found A (segment 6)."
The rule only fires when Source A matches one of your defined conditions. If Source A contains a value you haven't mapped, the rule is silent for that file — it neither passes nor fails. This means you can introduce segment consistency rules incrementally, starting with the most important pairings and adding more over time.
Practical examples of cross-field rules
Discipline-to-originator mapping
This is the most common use case. On most projects, each originator is responsible for one or two disciplines. The mapping is defined in the BIM Execution Plan or the Responsibility Matrix. In Foreman, you express this as a segment consistency rule where Source A is the originator (segment 2) and Source B is the discipline (segment 6).
Example: originator-to-discipline mapping
| Originator (Source A) | Allowed disciplines (Source B) | Role |
|---|---|---|
| ACE | A, L | Architect (architecture + landscape) |
| BKR | S | Structural engineer |
| CRN | M, E, B | MEP consultant (mechanical, electrical, building services) |
| DLT | C | Civil engineer |
| ELM | L | Landscape architect |
With this mapping in place, the file
PRJ-BKR-ZZ-01-DR-A-0015.pdf
would be flagged: originator BKR is only permitted to produce discipline S documents, but the file
has discipline A. Meanwhile,
PRJ-BKR-ZZ-01-DR-S-0015.pdf
passes without issue.
Form-to-discipline mapping
Some form types are only relevant to certain disciplines. For example, on many projects, the form code MO (model) is only valid for disciplines A, S, M, E, and C — the disciplines that produce 3D models. Discipline L (landscape) might only produce DR (drawings) and SP (specifications). A segment consistency rule with Source A as discipline and Source B as form catches files where a team has used the wrong form code for their discipline.
Suitability-to-document-type mapping
ISO 19650 suitability codes (S0 through S7, plus CR for "as constructed") indicate how a document may be used. On some projects, certain suitability codes are restricted by form type. For example, S0 (work in progress) might only be allowed for models (MO) and working drawings (DR), not for specifications (SP) or reports (RP) which are expected to be issued at S2 or above. A segment consistency rule enforces this constraint automatically.
Setting up a segment consistency rule
In your rule set, add a new rule and select the "Segment Consistency" type. The configuration has four parts.
1. Define Source A and Source B
Choose the two segments you want to relate. Source A is the "condition" segment — the one whose value determines what Source B is allowed to be. Source B is the "dependent" segment — the one being validated. For each source, specify the segment position in the filename (using the same delimiter and numbering as your other rules) or select from named segments if you've configured a naming template.
2. Add condition mappings
For each value that Source A can take, define the set of values that Source B must be drawn from. You add these as individual mappings: "When Source A = ACE, Source B must be one of [A, L]." Repeat for each originator (or whatever Source A represents). You can add as many or as few mappings as you need — unmapped Source A values are ignored.
3. Choose the value source
For the allowed values in each mapping, you have two options. You can enter them directly — type the values into the mapping. Or you can reference an existing validation list — select one of your stored lists, and the mapping will use its contents as the allowed values. The second option is useful when the same set of values is used in multiple mappings or when the list is maintained centrally and may be updated over time.
4. Configure the violation message
By default, the violation message includes the Source A value, the expected Source B values, and the actual Source B value. You can customize the message template to include human-readable descriptions — for example, "Originator {A} is not authorized to produce {B} documents" instead of the raw segment values. This makes the report more useful for team members who may not have the segment numbering memorized.
Direction matters
The mapping is directional. "If originator is ACE, then discipline must be A or L" is not the same as "if discipline is A, then originator must be ACE." The second form would prevent other originators from producing architecture documents. Think carefully about which segment is the condition and which is the dependent. In most cases, originator is the condition and discipline is the dependent, because each originator is assigned specific disciplines — not the other way around.
Combining segment consistency with other rule types
Segment consistency rules are most effective as the top layer of a multi-rule validation strategy. The recommended stack, in order of evaluation:
Naming convention (regex)
Validates overall structure. Catches files that don't have the right number of segments, use the wrong delimiter, or have character type errors. Files that fail here are fundamentally misnamed.
List validation (per segment)
Validates each coded segment against the approved list. Catches invalid individual values — unknown originator codes, non-standard discipline codes, retired form codes.
Numeric range (sheet number)
Validates the numeric segment is within bounds and correctly padded. Catches out-of-range numbers, missing leading zeros, and non-numeric characters in the number field.
Segment consistency (cross-field)
Validates that segment combinations are logically valid. Catches files where every segment is individually correct but the pairing contradicts the project's responsibility matrix.
This ordering matters for how you interpret results. If a file fails the naming convention rule, segment-level rules may produce misleading results (the segment positions might be wrong because the format is wrong). Process naming convention failures first, then move to segment-level issues. Foreman evaluates all rules in a single pass, but the results view groups violations by rule type so you can work through them in the right order.
If you're also using per-folder rule sets, you can apply different consistency mappings to different folders. This is useful on projects where different work packages have different originator-to-discipline assignments — a single rule set can't capture both, but per-folder mapping handles it cleanly.
Key takeaway
Single-field validation answers "is this value valid?" Segment consistency answers "is this combination valid?" On projects with multiple originators and disciplines, the second question is where the subtle, hard-to-catch errors live. A structural engineer accidentally tagging a file as architecture. An MEP consultant using a civil engineering discipline code. A model file with a suitability code that's only valid for specifications.
These errors pass every other check. They look correct at a glance. They only surface during a detailed audit — or when someone opens the wrong file at the wrong time. Segment consistency rules catch them automatically, on every check run, before they cause problems downstream. Combined with list validation and naming convention rules, you have a complete ISO 19650 compliance layer that validates structure, values, and relationships in a single pass.