Shared vocabulary — the code space, and where it is enforced
P-17 of Product Configurator § P states the etiquette: reuse the code, scope the value, never edit a global row. This page states the enforcement — which parts of the vocabulary the platform closes against invention, which it does not, and the three ways a product that follows the etiquette still ends up broken.
Provenance and status. From the PC 9951 run on the Ablera dev database, 31.08.2026 (Product Configurator § SRC, full text in the extract). The rules are structural; the counts are not repeated here because they drift — the estate prober measures them per environment and dates them (Product Configurator § A-19).
1. Codes are platform vocabulary, not product-local names
F Object codes, cover codes and factor codes are not scoped to a product: the same PERSON, the same FIRE, the same DURATION appear across many products, and downstream systems, rating grids and UI components key on them. Minting a near-duplicate — PERSON_2, FIRE_NEW, DURATION_D — is the most common way to make a product that configures cleanly, prices correctly, and then behaves oddly in the UI or fails to map downstream, because the component and the mapping were keyed to the original.
P So the default is reuse, and "is this code new?" is a query, every time — never an assumption. Where there is a hit, the shape to follow is that of the busiest existing user, read rather than guessed.
2. The three tiers, and knowing which one you are in
F Grouping the estate's factor and object codes by how many products use them gives three bands with different rules:
| Tier | Shape | Rule |
|---|---|---|
| core | used by most products — duration, payment frequency, the policy-level plumbing | never redefine; a new product almost always wants the existing rows |
| family | shared by a line of business — the covers and factors of a product family | reuse within the family; this is where a genuinely new product legitimately joins an existing vocabulary |
| tail | used by exactly one product | the only tier where inventing a code is right |
F Most factor codes live in the tail, so new factors are normal — but the tail is not where the policy-level plumbing lives, and that is exactly what gets wrongly re-minted. P The tier is established by running the distribution query, not by intuition about the code's name; the balance shifts as products are added, so the answer is dated.
3. Cover and object codes are enforced, and the set is closed
F PR_BASIC_COVERS.COVER_CODE and .OBJECT_CODE are foreign keys to LT_COVER_CODE and LT_OBJECT_CODE. Both lookups are two-column (ID, DESCR_LINK), and the gateway has no write command for any LT_* table — so from the endpoint path the set of usable cover and object codes is closed, and a code that is not already there is rejected with ORA-02291.
F The tables are nonetheless writable in SQL, so the ordered ways out are: map the document's cover onto an existing code whose meaning matches — nearly always right, and the reason the reuse rule exists; add the lookup row, label first because DESCR_LINK is a foreign key to the message table (Write Envelopes § 7); escalate only when the account genuinely cannot write it, confirmed by capability evidence; any zero-row DML probe still requires the write protocol.
F ⚠ This check belongs in modelling, not in apply, because nothing surfaces it until issuance: PPA_PRODUCT_COVERS has no foreign key to IPAL, so factors, rating and quotes all configure and price perfectly without a single IPAL cover row. A product can reach a correct, reconciled premium and have no covers at all.
P So S1 emits the document's cover and object codes as a set to be resolved against the lookups, and S2 may not claim the priced rung of the proof ladder for a product whose cover codes have not been confirmed to exist — Quote Verification § 6 already says a quote cannot see this.
F Object codes carry one constraint more: they are coupled to frontend components. The UI renders the object form from the object code, so an unrecognised one has no form even when the lookup row exists. Choosing PERSON for a person product is not a naming preference — it is what makes the object step render at all.
F ⚠ And it follows that a new object type is never just a lookup row. Adding one to the lookup makes it selectable and nothing more: the form still has no component to render, and where the product must also reach the incumbent system the type needs an object model and a product code on that side as well. P So "the specification names an object we do not have" is not a one-row change — it is a lookup row, a frontend component and, with the seam in scope, a handover at Hd. It is named in unresolved[] at S1, never discovered at S3.
F And a cover code does not imply one object: the same cover code appears against different object codes on different products, so (COVER_CODE, OBJECT_CODE) is the identifying pair. Copying a cover's setup from another product without confirming the object inherits a shape that does not fit.
4. Reusing a code is not inheriting a row
F ⚠ The most costly misreading of the reuse rule. Reusing a factor code means not minting a near-duplicate; it does not mean the product gets that factor for free. A product still needs its own PR_PRICING_FACTORS row for every factor it uses, with its own allowed values, even for the most universal ones. A product with no row for a shared factor does not inherit it — it simply does not have it, and the field renders as an empty dropdown the operator cannot fill.
F Observed: a product configured without its own rows for the duration and payment-frequency factors reached the UI with three empty required dropdowns and could not be quoted, while every one of those factors existed and was in use by dozens of other products. P This is a fourth cause of the empty-dropdown symptom of Stage IPAL § PF-8, and the one that looks least like a configuration error, because the codes are demonstrably present in the estate.
5. Reusing a code whose values are global merges two value lists
F "Reuse the code, scope the value" works when the existing values are themselves product-scoped. It does not work when they are global (PRODUCT_CODE IS NULL), because a global value applies to every product and adding your own alongside gives the operator one dropdown containing both sets.
P So the check before reusing a factor code is not does the code exist but what is the shape of its value list:
| What the value list looks like | What to do |
|---|---|
| no global rows — every live row carries a product | reuse the code, add product-scoped values |
| global rows whose meaning matches | reuse both; add nothing |
| global rows whose meaning does not match | mint a new code — reusing it would put both sets in one list |
The third row is the one case where creating a near-neighbour of an existing code is the right answer, and it is said out loud in the plan rather than done quietly. Observed shape: a factor global as Y/N where a product needed NONE/ONE/TWO_PLUS.
F The same holds for dependency rows and for labels: PR_PRICING_FACTOR_VALUES and PR_PRICING_FACTOR_DEPENDENT rows with a null PRODUCT_CODE are shared by every product, and a DESCR_LINK is a global message code — editing its text rebrands every product using it (Translations). Reuse the code, not the pointer: sharing a factor code is intended, sharing another product's rating file or message row usually is not.
6. Freeze the vocabulary before either surface is written
F A rating grid does not resolve on codes. Its row and column headers carry the factor name, and its cells are matched against the stored value strings character for character. A mismatch does not raise: the grid falls through to its catch-all band and prices the risk at whatever that band holds. The premium is wrong and there is no message.
P So the shared vocabulary — cover codes, factor codes, factor names and the value strings a grid must match — is frozen in the specification before either surface is written, and every stage that writes projects that section rather than re-deriving it. A factor renamed after a grid was authored is a defect in the making, and the round-trip diff exists to catch it.
P On a new product the whole class of mismatch is removable rather than manageable: set the factor's name equal to its code, so the code, the grid's header token and the engine's request key are one string with nothing left to keep in sync. Where an existing factor is reused and its name already differs, the difference is recorded in the specification as a deliberate asymmetry rather than left to be rediscovered.
7. A dividing line that settles most cases
P Reuse and minting stop being a judgement call once the question becomes what kind of thing is this factor:
- An attribute of the insured object — the vehicle's age, make, engine capacity, seats, fuel — is already captured on the object card. Reuse the platform's factor even when the document phrases it as a question, because a second factor over the same fact can contradict the first and the operator would answer it twice. A document band such as "up to 3 / 3–5 / 5–7 years" maps onto the numeric attribute exactly — and where the same document bands the same quantity differently in two sections (six bands for the main rate, three for an add-on), only the numeric attribute can serve both; a six-value list cannot.
- An answer about the risk, the policyholder or the history — usage, claims count, no-claims years, service arrangement, region — is the document's own vocabulary. Mint it when the platform's near-neighbour carries different values, and say so.
F ⚠ Watch the party, not just the name: a platform factor for the policyholder's region or age is not the same as a tariff rule keyed on the owner's or the lessee's, which differ on a leased vehicle. That difference is a reason to mint, and it is stated rather than glossed.
Challenges
- C Whether the tier distribution is measured once per customer at plug-in time or re-measured per case is open — it is the same question as the dated conventions of Product Configurator § A-19.
Related: Stage IPAL · Translations · Write Envelopes · Factor Sources · Product Configurator § P