STARK MDM Concept Lab | Experimental Solution

Status: Draft concept walkthrough Source date: 2026-04-01

Target master domains 3

MDM prototype records 11

Open approval tasks 0

Domains in experiment DB 12

Reference values 83

Mapping entries 13

Back to David's module

Reference Platform

Live workspace for the separate reference concept

The workspace below remains the live experimental area for governed reference domains, canonical values, and deterministic mappings. Functionally, this should stay separate from the MDM applications and instead be consumed by them for validation, translation, standards alignment, and controlled governance of shared dictionaries.

Branch Type

branch-type

No standard ACTIVE 4 values 1 mapping sets

Canonical Standards

canonical-standards

N/A ACTIVE 37 values 1 mapping sets

Capabilities

capabilities

No standard ACTIVE 4 values 0 mapping sets

Contact Type

contact-type

No standard ACTIVE 2 values 1 mapping sets

Country Codes

country-code

ISO-3166-1-A2 ACTIVE 5 values 2 mapping sets

Facility Type

facility-type

No standard ACTIVE 5 values 0 mapping sets

Location Class

location-class

No standard ACTIVE 7 values 0 mapping sets

Location Domain Type

location-domain-type

N/A ACTIVE 5 values 0 mapping sets

Location Types

location-type

No standard ACTIVE 3 values 0 mapping sets

Operational Status

operational-status

No standard ACTIVE 5 values 0 mapping sets

Payment Terms

payment-terms

No standard ACTIVE 2 values 1 mapping sets

Pricing Region

pricing-region

No standard ACTIVE 4 values 0 mapping sets

Open technical design reference

Design Principles

Solution baseline

Canonical first, with the group code as the primary contract.
Maker-checker as the default for all governed changes.
Effective-dated lifecycle for values and mappings.
API plus Kafka for bootstrap and ongoing distribution.

Governance

Rules that keep the model clean

Cross-domain translation is prohibited.
Mapping logic must remain deterministic and easy to explain.
Ownership, purpose, consumer list, versioning, and effective dates are mandatory metadata.
Approval actions require an elevated role and a full audit trail.

Reference API

Representative endpoints

GET /v1/domains GET /v1/domains/{domainId}/values POST /v1/domains/{domainId}/values/{code}/approve GET /v1/mapping-sets/{mappingSetId}/entries GET /v1/mappings/lookup?domain={domainId}&mappingSet={mappingSetId}&system={systemId}&code={externalCode} POST /v1/imports/mappings

Kafka Distribution

Topic strategy

stark.reference.domain.v1 stark.reference.value.v1 stark.reference.mapping.v1

Reference Data Model

Reference data model

The reference platform is built around four core structures: domains, canonical values, mapping sets, and mapping entries. Mapping sets hold the external system context, while mapping entries hold the actual external-code-to-canonical translation rows.

Visual ERD

Reference hierarchy at a glance

reference_domains

Reference Domain

Owns the governed reference area.

reference_values

Reference Value

Holds the canonical approved values.

mapping_sets

Mapping Set

Defines the external system context.

mapping_entries

Mapping Entry

Maps one external code to one canonical value.

reference_domains

Reference Domain

Defines the governed reference area such as location-class, branch-type, or facility-type.

id (PK): Unique identifier for the domain record.
domain_key: Stable technical key such as `location-class` used in APIs and integrations.
name: Human-readable display name for the domain.
description: Business explanation of what the domain is used for.
canonical_standard_value_id: Optional reference to the standard that governs this domain.
format_rules: Rules for how canonical codes or values should be formatted.
owner_name: Function or team accountable for the domain.
steward_name: Named steward responsible for maintaining the domain.
status: Lifecycle state of the domain such as DRAFT or ACTIVE.

reference_values

Reference Value

Stores the canonical values that downstream systems and MDM should use as approved targets.

id (PK): Unique identifier for the canonical value row.
domain_id (FK -> reference_domains): Links the value to its parent domain.
canonical_code: Stable canonical code such as `PHYSICAL_SITE` used by MDM and integrations.
label: Business-facing label shown in UI and documentation.
description: Explains the meaning and intended use of the value.
status: Lifecycle state of the value such as DRAFT, ACTIVE, or RETIRED.
valid_from: Date/time when the value becomes valid for use.
valid_to: Date/time when the value should stop being used.

mapping_sets

Mapping Set

Defines one translation context for an external system such as SAP, Informatica, or a legacy ERP.

id (PK): Unique identifier for the mapping set.
domain_id (FK -> reference_domains): Links the set to the domain whose values it translates.
set_key: Stable technical key for the set, for example `sap-location-class`.
name: Business-facing name of the translation context.
external_system: The external source system this set belongs to, such as SAP.
purpose: Why this mapping set exists and what process it supports.
owner_name: Responsible owner for the translation contract.
consumer_list: Systems or teams expected to consume this mapping set.
version_label: Optional business version for the set.
status: Lifecycle state of the set such as DRAFT or ACTIVE.

mapping_entries

Mapping Entry

Stores one concrete mapping row from an external code inside a set to one canonical value.

id (PK): Unique identifier for the mapping row.
mapping_set_id (FK -> mapping_sets): Links the row to the mapping set that defines the external system context.
target_value_id (FK -> reference_values): Links the row to the canonical value that this external code should resolve to.
external_code: The raw code or value coming from the external system.
canonical_target_code: Cached canonical code for easy lookup and audit readability.
status: Lifecycle state of the mapping row.
valid_from: Date/time when the mapping row starts to apply.
valid_to: Date/time when the mapping row should no longer be used.

Relationships

How the reference entities connect

Reference Domain 1 -> many Reference Values
Reference Domain 1 -> many Mapping Sets
Mapping Set 1 -> many Mapping Entries
Reference Value 1 -> many Mapping Entries

Reference Flow Example

Example flow with SAP mappings

This example shows how a governed reference domain is structured when SAP values are translated into canonical STARK values.

Domain

location-class

The governed reference area that defines what kind of classification we are managing.

Value

PHYSICAL_SITE

One canonical value inside the domain that downstream systems and MDM use as the approved target.

Mapping set

SAP Location Class

The translation context for one external system or source family. The external system belongs here, not on every mapping row.

Mapping entry

Production Site -> PHYSICAL_SITE

One concrete translation row inside the set that maps an external code to the chosen canonical value.

Example Data

Domain and Canonical Value

Domain: Location Class (location-class) Status: ACTIVE Canonical Value: Physical Site (PHYSICAL_SITE) Value Status: ACTIVE

Physical site or real-world location.

Translation Context

Mapping Set

Name: SAP Location Class External System: SAP Set Key: sap-location-class Status: ACTIVE

Translate SAP location type values into canonical STARK location classes.

Mapping Entries

Rows inside the SAP mapping set

External code External label Canonical target Status

Production Site Production Site PHYSICAL_SITE ACTIVE

Delivery Point Delivery Point DELIVERY_POINT ACTIVE

Legal Address Legal Address LEGAL_ADDRESS ACTIVE

Open document alignment notes

TD Alignment

What is aligned and what needs confirmation against TD

Aligned with FD/TDD

Governed reference hierarchy

The prototype now expresses the reference solution as Domain, Value, Mapping Set, and Mapping Entry, which is consistent with the target design intent around governed canonical values, translation contracts, and reusable shared dictionaries.

Aligned with FD/TDD

Canonical value ownership

The documents describe reference management as a governed source for canonical values, mappings, and validation inputs. The prototype follows that direction by treating canonical values as the approved targets for MDM and integration translation.

Needs confirmation

Mapping set as the external system context

The prototype now places external system context on the Mapping Set rather than on each individual Mapping Entry. This is a cleaner and more maintainable model, but it should be made explicit in the target design if this is the intended production structure.

Aligned with FD/TDD

Prototype versus production implementation

The technical design points toward production-grade APIs, event contracts, migration controls, and runtime topology. The prototype intentionally documents and visualizes those ideas without claiming to be the final implementation.

TD Gap Analysis

How the current reference prototype maps to TD

Area, current state, next step

FD/TD Area Prototype Status Recommendation

Aligned

Reference hierarchy and ownership model

Well represented. The prototype now makes the reference structure explicit as Domain, Value, Mapping Set, and Mapping Entry, with clear ownership and governance separation from MDM.

Keep this hierarchy as the reference baseline and use it consistently in UX, documentation, and target platform contracts.

Aligned

Canonical value governance

Implemented conceptually and functionally. Domains and canonical values have lifecycle states, stewardship-oriented editing, and are positioned as the approved canonical layer for MDM and translation.

Preserve this model and ensure the target implementation continues to treat canonical values as governed business assets rather than lightweight lookup rows.

Aligned

Mapping context on mapping set

Aligned with the clarified model. External system context now sits on the Mapping Set, and Mapping Entries behave as translation rows inside that set.

Carry this into the target data model so translation context is defined once per set and not duplicated per entry.

Partial

Maker-checker and workflow depth

The prototype supports governed editing and lifecycle states, but it does not yet behave like a fully configurable maker-checker engine with richer workflow branching, delegated approvals, or emergency-change handling.

Model reference workflow as a configurable governance service in the real platform, especially for approvals, exceptions, and audit-sensitive changes.

Partial

Import, bulk maintenance, and operational tooling

The prototype is usable for manual stewardship, but bulk import/export, controlled migration tooling, and operator runbooks are still described only in documentation.

Treat bulk operations, migration workbooks, and operational runbooks as first-class deliverables for the target platform implementation.

Partial

Reference API and event contracts

Representative endpoints and Kafka topics are documented, but they are not implemented as the final production-ready API/event surface in this prototype.

Use the prototype as a contract discussion aid, then let the target-platform developers formalize OpenAPI specs, event schemas, and versioning rules.

Aligned

Deterministic translation model

Strongly aligned. The prototype clearly treats mappings as deterministic translation rows from external values to canonical targets, which matches the intended role of the reference platform.

Keep mappings explainable and single-purpose, and avoid mixing business-rule logic into simple reference translation rows.

Gap

Target runtime and non-functional implementation

Not implemented in target form. The prototype does not realize the production reference runtime concerns such as isolated environments, resilience controls, observability, topic lag handling, backup/restore, or deployment topology.

Treat the prototype as a functional and structural walkthrough only, and let the real platform implementation carry the non-functional design from TD.

Gap

Migration from Reference 360

Only documented at concept level. The prototype does not implement migration sequencing, dual run, reconciliation, or cutover controls from the current reference solution.

Plan migration as a dedicated workstream with domain inventory, cutover sequencing, dual-run strategy, and validation checkpoints outside the prototype codebase.

Reference Overview Alignment

What is aligned with the uploaded functional reference document

Aligned with Reference Overview

Reference data as standardized values and classifications

The prototype reflects the uploaded document's core definition of reference data by centering the solution around governed lists of values, canonical codes, and classifications that give meaning to master and transactional data.

Aligned with Reference Overview

Centralized source for list of values and standard codes

The current reference model supports both enumerated values and mappings from application-specific codes to Stark canonical codes, which matches the document's stated purpose for Stark.

Partial fit

Approval workflow, audit, and RBAC

The uploaded document expects approval workflow, auditing, and portal role control as core functional requirements. The prototype shows lifecycle states and stewardship-oriented editing, but it does not yet implement these controls with full operational depth.

Reference Overview Gap Analysis

How the current reference prototype maps to the uploaded overview document

Area, current state, next step

Reference Overview Area Prototype Status Recommendation

Aligned

List of values and canonical code mappings

Strong fit. The prototype supports governed values, canonical codes, and mappings from external application codes to Stark canonical targets.

Keep this as the functional heart of the reference solution and use it as the baseline for user walkthroughs.

Aligned

Centralized reference ownership

Strong fit. The prototype treats reference data as a separate, shared capability rather than embedding lists and mappings inside each consuming domain flow.

Preserve this separation so the reference platform remains the single source of truth for shared dictionaries and code translation.

Partial

Approval workflow before changes take effect

Only partially implemented. Statuses exist, but the reference solution does not yet enforce a full maker-checker workflow before changes become effective.

Add explicit approval flow for domain, value, mapping set, and mapping entry changes so the functional behavior matches the uploaded document.

Partial

Audit of who changed what and when

Only partially covered. The prototype has timestamps and stewardship metadata, but not a true audit trail per change event.

Introduce audit events or history views for reference changes so administrators can inspect actor, time, and before/after state.

Gap

Bootstrap from external sources

Not implemented. The uploaded document calls out files, databases, and Kafka as bootstrap sources, but the prototype currently relies on manual stewardship and seeded data.

Add import/bootstrap capabilities later as a dedicated functional workstream once the core stewardship model is stable.

Gap

EDC/data dictionary feed

Not implemented. The prototype documents the idea of discoverable dictionaries but does not expose a feed or export that could support EDC.

Model this as a later capability in the target reference platform, not as part of the current walkthrough prototype.

Partial

RBAC on the user portal

Only lightly covered. The site has login and some coarse permissions, but not role-based control designed specifically for reference stewardship responsibilities.

Treat reference-specific RBAC as a real target requirement and design it properly in the production platform.