Model Hierarchies and Reference Data in EBX 6.2.3

A governed product hierarchy connected to reference data, effective-time layers, semantic relationships, and AI endpoints. — Part 7: Hierarchies, Reference Data, and Semantic Context

An entity can be perfectly matched and still be misunderstood. A product named “TrailBlazer 2” is not analytically useful until systems agree that it is footwear, belongs to Outdoor, uses a controlled lifecycle status, and rolls up to the same hierarchy on the same date.

Part 6 established accountable decisions. This workshop governs the semantic context around those decisions: controlled code sets, product/category relationships, hierarchy versions, and the labels AI applications may show to people.

Audience and prerequisites

This chapter is for data modelers, reference-data stewards, enterprise architects, BI modelers, knowledge engineers, and AI/RAG engineers. You need the Product domain from Part 3, a writable workshop dataspace, model-authoring permissions, and synthetic records only.

Learning outcomes

At the end you will have:

A governed category hierarchy with explicit parent relationships.
Controlled lifecycle and market code tables.
Effective dates and status suitable for reproducible consumption.
A role-appropriate EBX hierarchical view.
A semantic contract that prevents labels from becoming identifiers.

Version note: Steps target EBX 6.2.3. Classic UI paths may differ in the 6.2.3 preview UI. Hierarchical views are a display of modeled relationships—not a replacement for the foreign keys and constraints in the model.

The modeling decision

Treat reference data as mastered data when it changes business meaning. The code DISC should have a stable identifier, governed label, definition, owner, status, and validity period. Never make a mutable English label the integration key. For multilingual or AI-facing use, labels are presentation; codes and URIs are identity.

Synthetic workshop data

csv

category_id,parent_category_id,label,definition,status,valid_from,valid_to
CAT-ROOT,,All Products,"Enterprise product root",ACTIVE,2026-01-01,
CAT-OUT,CAT-ROOT,Outdoor,"Products intended for outdoor use",ACTIVE,2026-01-01,
CAT-FTW,CAT-OUT,Footwear,"Wearable products for the feet",ACTIVE,2026-01-01,
CAT-TRL,CAT-FTW,Trail Shoes,"Footwear designed for trail running",ACTIVE,2026-01-01,

csv

code,label,definition,status,replaced_by
ACTIVE,Active,"Available for normal commercial use",ACTIVE,
DISC,Discontinued,"No longer manufactured; may remain serviceable",ACTIVE,
RET,Retired,"Invalid for new assignment",RETIRED,DISC

csv

product_id,product_name,category_id,lifecycle_code,market_code
P-2048,TrailBlazer 2,CAT-TRL,ACTIVE,US
P-2051,TrailBlazer 2 Wide,CAT-TRL,ACTIVE,CA

Hands-on: build governed context — expanded executable procedure

Exact EBX 6.2.3 classic/preview labels and configured services vary; verify them in the licensed environment and work only in isolated non-production data.

Actions: In a non-production EBX 6.2.3 model, create LifecycleStatus and Market with stable primary keys, label, definition, owner, status, validity dates, and successor. Add date-order, no-self-successor, active-successor, and no-new-retired-assignment controls. Replace Product magic strings with osd:tableRef foreign keys, then validate/publish only to the workshop dataset. Expected result: stable codes persist and invalid references cannot save. Validation: test valid, unknown, retired, self-successor, and reversed-date cases. Stop/recovery: cancel publication and build an approved crosswalk if existing values do not map uniquely.

Actions: Create Category with stable ID, optional self-referencing parent, label, definition, steward, status, and validity. Add self-parent prevention plus full ancestor-cycle detection through the installed environment’s supported constraint/procedure. Test root, child, and three-level records. Expected result: ROOT → Outdoor → Footwear → Trail Shoes persists while A→B→C→A is blocked. Validation: traverse ancestors and attempt the cycle. Stop/recovery: block hierarchy writes and use administrator-reviewed imports if complete cycle detection is unavailable.

Actions: Create a hierarchical view using the recursive parent reference, show ID/label/status/validity, save Product taxonomy — steward, and grant only appropriate steward access. Compare every rendered edge with stored parent IDs. Expected result: the exact governed tree displays without invented levels. Validation: edge-by-edge reconciliation. Stop/recovery: do not enable skip-level behavior to conceal defects; correct data/view settings or return users to tabular view.

Actions: Snapshot the known-good workshop state. Import Category, LifecycleStatus, Market, then Product in dependency order; reconcile counts and validate. In separate disposable children, test a cycle, retired assignment, reversed validity, and deletion of referenced CAT-TRL; record exact rules/messages and discard each child. Expected result: valid data loads and all four invalid operations are blocked. Validation: expected counts, zero good-state errors, four rejection records. Stop/recovery: never merge a child where an invalid operation succeeds; restore snapshot, disable writes, and fix the missing control.

Actions: Export ID, label, definition, parent ID, status, validity, and dataset version. Validate IDs/parents against the released dataset and reject inactive/nonexistent generated codes. Rename the Trail Shoes label without changing CAT-TRL. Expected result: consumers show the new label while identity and history remain stable. Validation: schema/referential checks and before/after payload comparison. Stop/recovery: pause release and migrate any label-keyed consumer before renaming.

Actions: Validate the child and create read-only snapshot PRODUCT-2026-10-28 using the installed snapshot workflow. Record snapshot identity in payloads; query it, change a label only in the writable child, then query both. Expected result: current data changes while snapshot label and stable ID remain reproducible. Validation: preserve both responses and confirm snapshot writes fail. Stop/recovery: stop consumer release, verify endpoint/dataspace selection, and recreate from the last known-good state if snapshot behavior drifts.

AI-era governance context

Hierarchy paths are compact grounding context: All Products > Outdoor > Footwear > Trail Shoes. Yet an LLM may invent a plausible missing category or treat neighboring nodes as synonyms. Prevent this by returning allowed identifiers from EBX, validating generated identifiers against the code table, and rejecting non-existent or inactive codes. Retrieval relevance never grants write authority.

Use definitions to disambiguate terms, aliases for search, and stable IDs for action. If you later map these records to an ontology, preserve provenance—W3C PROV describes entities, activities, and agents as a basis for representing how information was produced (W3C PROV overview).

Validation checklist

Not completed: No free-text field duplicates a governed lifecycle or market code.
Not completed: Every foreign key resolves.
Not completed: Self-parent and multi-node cycles are blocked.
Not completed: Codes have definitions, owners, status, and validity dates.
Not completed: Retired codes cannot be newly assigned and have an explicit successor where appropriate.
Not completed: The hierarchical view matches the persisted parent relationship.
Not completed: A snapshot reproduces the earlier hierarchy and labels.
Not completed: AI-facing payloads include stable IDs and a dataset/snapshot version.

Failure modes

Failure	Consequence	Better pattern
Label used as primary key	Renaming breaks integrations	Stable code plus mutable localized label
Hierarchy exists only in BI	Each consumer invents a roll-up	Govern parent relationships centrally
Cycle detection omitted	Traversal and aggregation fail	Validate the complete ancestor chain
“Unknown” and null conflated	Meaning becomes ambiguous	Govern explicit unknown/not-applicable codes
Retired code deleted	Historical facts become unreadable	Retain and mark inactive with successor
Vector similarity selects code	Plausible but invalid classification	Retrieve candidates, then validate the ID

Takeaway

Master data identifies the nouns; reference data and hierarchies provide their grammar. For AI, governed semantics reduce ambiguity. For auditors, versioned semantics make past outputs reproducible. For people, definitions turn a code list into shared meaning.

Next in the series

Part 8 will move this governed context beyond EBX. We will design inbound and outbound contracts, idempotent synchronization, REST access, events, and distribution without creating a second unmanaged master.

Illustration brief

Hero concept: A bright, editorial taxonomy tree centered on a highlighted product. Stable code badges sit beneath human-readable labels; a timeline slider shows the same hierarchy at two governed versions. A small AI retrieval card cites the exact node and version.

Alt text: “A product links to governed category and reference-data nodes with stable identifiers, definitions, effective dates, and a version cited by an AI retrieval response.”