How a header's answer is decided

Every way a decodification header gets its answer — gates, inheritance, mappings, hard limits and conditional defaults — in the order they apply, with an example of each.

A header’s answer in a datasheet’s configuration is decided by several mechanisms. Each answers a different question, and they apply in a fixed order. This page lists them, shows the order, and gives one example each. The mechanisms are set up in the datasheet editor; see Decodification Master for the editor itself.

Mappings, gates and inheritance apply to item codes and to the datasheet preview. Hard limits and conditional defaults steer only the preview for now; see Limitations.

The mechanisms at a glance

A requested option is one asked for in the datasheet preview, or an answer an item code was released with.

Five of these change a header’s menu or answer in ways that are easy to confuse:

The order they apply in

Where a step names an option “allowed”, the option is not marked not applicable, sits inside its hard limits, and is one the mappings that apply to the header permit.

Three consequences worth knowing:

• A requested option is not replaced by a mapping’s default, a conditional default or an inherited material. Those only fill in a header nobody asked about. What limits a request: the mappings that apply refuse an option none of them allows (an item code carrying one is not saved), a hard limit drops it when the enquiry falls outside its range, and a gate hides it.
• Gate and Inherit run last. They read the answers the earlier steps produced, so a header can be gated on a parent whose own answer came from a mapping. The reverse does not hold: mappings, hard limits and conditional defaults read a header’s answer before its gate or inherited material is applied.
• When step 4 moves a header, the mappings that read it are applied again. The headers those mappings decide follow the move, and any option requested for them is put back, unless a hard limit dropped it.

Which one do I use?

The questions are not exclusive. A header can gate and inherit, and can also be decided by other headers; the chart names the mechanism each need points to.

One example each

Gate. The metal tube rotameter’s JACKETING MOC carries a “Jacketing Not Applicable” option, and Jacketing Size, Jacketing Fluid and Jacketing Temp. gate on it. Pick “Not Applicable” and none of the three is asked, and none prints a segment in the model number.

Inherit. The electromagnetic flowmeter’s EARTHING MOC is asked always, but when EARTHING TYPE is “In-Built Electrode” it fills itself with the same metal as ELECTRODE MATERIAL, under its own code for that position. “Earthing Ring” leaves it to be asked.

Decided by, one header. The tubular level indicator’s CAGE MOC decides SCALE MOC. MS takes an acrylic scale mounted separately; every other cage material takes the scale engraved directly. Two mappings cover every cage material: one names MS, the other names the rest.

Decided by, one header, two answers. FLANGE MOC decided by IBR TYPE. Non-IBR allows CS and SS 316 with CS the default; IBR allows CS only. A released code that is IBR cannot choose SS 316.

Decided by, two headers together. (An illustration, not a live master.) Body lining is decided by Inlet lining and Outlet lining together:

Each of the first three rows is one mapping: the first header (IF), an AND line on the second, and the answer (THEN). The last row is not a mapping; it is what happens where no mapping applies. A mapping applies only while all its conditions hold, and the answers of the mappings that apply are the only ones the header offers. A pair no mapping names leaves the header open, on its own default. Where one pair is named by mappings with different answers, exactly one carries the Default mark.

A saved mapping that gains an unfinished AND line, one naming no choice yet, is left out of the next published version and shown as removed in the publish review. A mapping never published is not counted until it is complete. A header’s mappings may together involve at most 10,000 combinations of choices; publishing is refused beyond that.

Hard limit and conditional default. An electromagnetic flow meter’s Lining header: PFA only survives −1 to 2 bar, so that is its hard limit. Three conditional defaults pick when nobody chose a lining: pressure −0.99 to 1 bar picks PFA, size 15–80 NB picks PTFE, size 100–2000 NB picks Rubber. An enquiry at −0.5 bar gets PFA. One at −0.5 to 5 bar cannot have PFA at all, because part of the range is outside PFA’s limit, so the next rule that still fits decides.

One header through all of it

An illustration built on the FLANGE MOC example: a flange material header, decided by IBR TYPE, whose options carry a hard limit on pressure, in a datasheet preview whose enquiry states a pressure. Say its own default is CS.

1. It starts at its own default, CS.
2. Nobody requested a flange material, so nothing is laid over it.
3. The line’s IBR TYPE is Non-IBR, so the Non-IBR mapping applies: CS and SS 316 are allowed, CS is the default.
4. The enquiry’s pressure is inside both options’ limits, so neither is dropped. No conditional default is set, so the mapping’s default, CS, stands.
5. It has no parent, so no gate applies and nothing is inherited.

The line answers CS, and SS 316 stays on the menu. Had the customer asked for SS 316 it would stand, since it is inside its limit. Had the enquiry’s pressure fallen outside SS 316’s limit, that request would be dropped and reported, and the header would answer CS.

What a header cannot do

• A header’s gate and material follow one parent. Only its answers can be decided by two or more headers together.
• There is no “any other choice” catch-all. A mapping names the choices it applies to; a choice added later is answered by no mapping until one names it.
• Nothing scores an option against enquiry conditions except hard limits and conditional defaults.

See Limitations for the full list, and Business rules for R60 to R63.