Decodification Master

The family's option menus — how a model number is built, segment by segment, and why a code is positional.

Decodification is the menu of specification options for one family, and the rules that turn those choices into a Flowtech model number (order code).

The composed number is the order code. There is no separate mapping from “configuration” to “something the factory understands”.

How a model number is built

Take an electromagnetic flowmeter line:

Start with the group’s model prefix (FMIPL-VTFM).
Walk each coded position in the master, in order.
Append that position’s option code (FT2, PC1, PCS1, …).
Skip positions that do not apply to this order.

The result is unique to this quotation line. A different lining tomorrow is a different string, still on the same item code.

Positions, not a bag of materials

Option codes are positional. SS 304 on the flowtube is not the same code as SS 304 on the process connection:

Position	Code	Value
FLOWTUBE MOC	`TS1`	SS 304
PROCESS CONNECTION MOC	`S1`	SS 304
COIL HOUSING MOC	`CH2`	SS 304

A shared “SS 304” library entry can still carry the material’s corrosion behaviour and price basis. The code that prints on the model number belongs to the position. Flattening codes across positions is how a product list stops matching the client’s workbook.

Headers that depend on each other

A position can name two independent constraints against the header above it, in the same master — never one merged “depends on” setting:

Gate — ask this header only when its parent is actually in play. A transmitter’s voltage is never asked on a line with no transmitter, and a gated-off header contributes no segment to the model number, the same as any other position that does not apply.
Inherit — take the parent’s material and resolve to the matching code on this header’s own position, never the parent’s code (see “Positions, not a bag of materials”). Left open, inheriting follows whatever the parent resolves to; it can also be narrowed to specific parent choices.

A header may gate without inheriting, inherit without gating, both, or neither — voltage-style headers gate on their transmitter without inheriting its material; MOC-style headers inherit without being hidden.

One option on a header can also be marked not applicable — “Transmitter Not Required” rather than a real answer. A header gated on a parent needs that parent to carry one of these, or the gate can never fire.

A position can also name which enquiry conditions — fluid, operating temperature, operating pressure, density — it should eventually be judged against. Nothing scores an option against them yet; naming them today prepares the ground for the rule engine that will (see Limitations).

Every choice is marked:

Marking	Meaning
Allowed	Nothing stated rules it out
Ruled out	A stated requirement provably breaches a known rating, with the reason
Unconfirmed	We could not check it — missing parameter, or no rating. Still selectable

Custom is never ruled out (R32). It is how an enquiry stays quotable when nothing in the menu survives.

A menu where every option is ruled out is a line-level problem — this family is wrong for the duty — not an empty dropdown (R33).

What the customer stated outranks family defaults (R34). A default filled over something they asked for is printed as a deviation (R35).

Versions

A published menu is immutable. Editing the master writes a new version. A quotation line pins the version it was built from, so a sent document never silently changes when applications engineering corrects a menu next month.

The group’s “current master” pointer is which menu new lines start from. Old lines keep the version they used.

What the business does here

Maintain the blocks: which positions exist, which codes, which are defaults, which parts are wetted (the process fluid actually touches them).
Publish a new version when a datasheet or the product list changes.
Never edit a version in place — that would rewrite history on sent quotes.