--- title: How a header's answer is decided description: 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. sidebar: label: How answers are decided order: 13.5 --- 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](/business/features/decodification) 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](/business/limitations). ## The mechanisms at a glance | Mechanism | The question it answers | Set on | Editor label | | --- | --- | --- | --- | | Header default | What is the answer when nothing else says? | An option | **Default** beside the option | | Not applicable | Is there nothing here to choose? | An option | **N/A** beside the option | | **Gate** | Is this header asked at all? | The header | **Visibility** | | **Inherit** | Should it take the material another header resolved to? | The header | **Material** | | **Decided by** | Which answers do one or more other headers' choices allow? | The header | **Allowed answers**, with **Add condition** (an **AND** line) for more headers | | **Hard limit** | Can this option be supplied at the enquiry's conditions? | The option | **Hard limits** | | **Conditional default** | Which option is picked for the enquiry's conditions? | The header | **Conditional defaults** | | A requested option | What did the person configuring, or the item code, ask for? | The configuration | — | 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: | | What it does to the menu | What it does to the answer | | --- | --- | --- | | Gate | Removes the whole header | Nothing is asked and no segment prints | | Decided by | Limits the menu to the named answers | Fills in the answer, or the marked Default where several are allowed | | Hard limit | Removes one option outside its working range | Never picked, even when requested | | Conditional default | Leaves the menu alone | Picks among the allowed options | | Inherit | Leaves the menu alone | Copies the source header's material | ## The order they apply in ```mermaid flowchart TD start["1. Every header starts at its own default"] --> stated["2. Requested options are laid over the defaults"] stated --> decided["3. 'Decided by' mappings settle every header they decide,
reading the values above; a requested option is not replaced"] decided --> enquiry{"Does the enquiry state a condition
this header's limits or conditional defaults use?"} enquiry -- yes --> limits["4. A requested option that fails a hard limit is dropped and reported.
A header with no requested option picks the first conditional default that meets,
else the mapping default, else its own default, else the only allowed option"] enquiry -- no --> links limits --> links["5. Parent links, each header after its parent:
a gate removes the header when the parent's choice does not admit it,
otherwise inherit fills it from its source unless an option was requested for it"] ``` 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? ```mermaid flowchart TD q1{"Should the header sometimes
not be asked at all?"} -- yes --> gate["Gate"] q1 -- no --> q2{"Should it take its material
from another header?"} q2 -- yes --> inherit["Inherit"] q2 -- no --> q3{"Should another header's choice
limit or fill its answer?"} q3 -- yes --> decided["Decided by
(add an AND line for more headers)"] q3 -- no --> q4{"Is an option only usable
in an operating range?"} q4 -- yes --> limit["Hard limit"] q4 -- no --> q5{"Should the default change
with the enquiry's conditions?"} q5 -- yes --> cond["Conditional default"] q5 -- no --> plain["Header default"] ``` 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: | Inlet lining | Outlet lining | Body lining | | --- | --- | --- | | Rubber | Rubber | Rubber | | Rubber | PTFE | PFA | | PTFE | PTFE | PTFE | | any other pair (no mapping) | | Body lining's own default | 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](/business/limitations) for the full list, and [Business rules](/business/business-rules) for R60 to R63.