PoR Field Collision Check — “model” Ambiguity#

Evidence collected during Phase 2I-4 first compilation run (2026-03-25).

Question#

Does “model” create ambiguity between D2 type (the element type in the naming grammar) and PoR field #40 (ModelUsedIn)?

Findings#

Status: Minor collision, manageable.

  1. In labels: model does not appear as a D2 type ID in the registry. The D2 type IDs are ax, th, con, pro, etc. No collision at the label grammar level.

  2. In field names: PoR field #40 is named model (brief code) with full name ModelUsedIn. This field records which D1 model(s) use a given element (e.g., “PET”, “JUB”, “PET+JUB”).

  3. Potential confusion: When discussing “the model field,” it is ambiguous whether one means D1 (which axiom system) or field #40 (which records the D1 value). In practice, field #40 is the storage location for the D1 dimension value. They refer to the same concept from different angles.

  4. In compiled pages: The expert view uses **ModelUsedIn (model):** as the field heading. This is clear in context but could be confusing in isolation. No actual collision occurred during compilation.

Recommendation#

No action needed for the current compilation. If a future D2 type named model were proposed, it would collide with the D4/D5 parser disambiguation. The registry discipline (Section 3.2 of the AHA doc) already prevents this. The conceptual overlap between D1 and field #40 is acceptable because they are semantically identical — field #40 records which D1 value applies.

Summary#

The “model” term appears in both the D1 dimension name and PoR field #40, but they refer to the same concept. No collision at the label grammar level. No D2 type model exists or is needed. The current architecture handles this correctly.