GEDRM 0.1 — Generic Enterprise Data Reference Model

1. Specification Identity

Attribute	Value
Specification	Generic Enterprise Data Reference Model
Acronym	GEDRM
Version	0.1
Status	Normative Draft Baseline
Specification Type	Reference Model
Scope	Enterprise Data
Primary Companion Architecture	Generic Enterprise Data Reference Architecture (GEDRA)
HDIP Relationship	Generic semantic foundation with explicit HDIP specializations
Normative Semantic Authority	This human-readable specification

1.1 Version Identifier

The canonical version identifier is GEDRM 0.1.

1.2 Semantic-Lock Status

GEDRM 0.1 incorporates the completed semantic-lock decisions for:

authority and sourcing roles;
Provider / Publisher / Distributor / Broker boundaries;
Master Data / Reference Data / Transactional Data / Market Data;
Derived provenance and Mastered processing state;
Source Data treatment;
Golden Record semantics;
Data Policy / Policy as Code / Data Contract / Data Quality Rule / Data Control;
Control Evidence;
privacy-law Data Controller / Data Processor placement;
external Data Requirement traceability;
sparse, semantics-driven cardinalities;
formal concept-kind taxonomy;
JSON-LD / RDF / OWL / SHACL representation principles.

The 0.x version family remains open to backward-compatible refinement before the first stable 1.0 release.

2. Purpose

GEDRM defines a reusable, technology-independent vocabulary and conceptual model for describing enterprise data, including its meaning, authority, provenance, processing, movement, provision, productization, consumption, governance, legal/privacy context, and assurance.

GEDRM provides a stable semantic foundation from which:

enterprise and domain Data Architectures can be described consistently;
GEDRA can organize those semantics into reusable architectural structures;
programme and solution architectures can be mapped and assessed;
Data Management requirements can refer to stable concepts;
HDIP can specialize generic data concepts without redefining them;
domain, regulatory, privacy, and enterprise-specific profiles can extend or constrain the model explicitly;
machine-readable ontology and validation artefacts can be derived.

GEDRM deliberately separates a semantic concept or logical role from the application, platform, service, person, organization, data store, or technology that realizes it.

3. Scope

GEDRM covers:

data origination and production;
authoritative business state, authoritative sourcing, and authority designation;
transformation, transport, provision, publication, distribution, and brokering;
Data Objects, Data Assets, and Data Products;
business/semantic data classification;
provenance and processing/governance state;
mastered representations and Golden Records;
receipt and consumption;
ownership, stewardship, custody, product ownership, and control ownership;
Data Policy, Data Contract, Data Quality Rule, Data Control, Policy as Code, and Control Evidence;
privacy-law Data Controller and Data Processor roles;
Processing Activity and related contextual role semantics;
external requirement traceability;
minimal semantic cardinalities;
machine-readable formalization and profile extension.

GEDRM does not prescribe:

physical database design;
vendor products;
application or infrastructure topology;
implementation protocols;
detailed security architecture;
detailed process workflows;
jurisdiction-specific legal interpretation beyond generic privacy-role placement;
enterprise-specific operating-model constraints unless provided through a profile.

4. Normative Language

The key words MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY are normative.

MUST — mandatory for GEDRM conformance.
MUST NOT — prohibited for GEDRM conformance.
SHOULD — expected unless a justified alternative exists.
SHOULD NOT — discouraged unless justified.
MAY — optional.

5. Core Modelling Principles

GEDRM-P-001 — Technology Independence

GEDRM concepts MUST remain meaningful independently of a particular vendor, cloud, database, transport technology, or application.

GEDRM-P-002 — Role / Realizer Separation

A role is not the same thing as the actor, system, service, platform, or artefact that performs or realizes it.

GEDRM-P-003 — Role Co-location

A single implementation component MAY perform multiple GEDRM roles without those roles becoming semantically equivalent.

GEDRM-P-004 — Scoped Authority

Authority MUST be stated for a defined scope.

Architectures SHOULD state:

System X is the System of Record for Payment Instruction state.

rather than:

System X is the source of truth.

Authority MAY vary by entity, attribute, lifecycle stage, business process, jurisdiction, consumer purpose, or other governed scope.

GEDRM-P-005 — Authoritative vs Authorized

Authoritative means recognized as having authority concerning validity, trust, or approved sourcing for a defined data scope.

Authorized means permitted or approved to perform a role.

The terms MUST NOT be treated as synonymous.

GEDRM-P-006 — Faceted Classification

GEDRM classification is multi-dimensional.

Data MAY simultaneously have a business/semantic category, provenance classification, processing/governance state, and legal/sensitivity classification where these dimensions apply.

Physical co-location MUST NOT imply semantic equivalence.

GEDRM-P-007 — Smallest Meaningful Scope

Classification SHOULD be assigned at the smallest meaningful semantic scope rather than inferred solely from the containing database, table, system, Data Product, or file.

GEDRM-P-008 — Explicit Specialization

Industry-, domain-, enterprise-, or platform-specific terminology MAY specialize GEDRM concepts. A specialization MUST identify its generic GEDRM parent concept where one exists.

GEDRM-P-009 — Semantic Necessity Cardinality

GEDRM core cardinalities MUST express semantic necessity rather than common implementation preference.

Stricter operating-model or implementation cardinalities SHOULD be defined in profiles.

GEDRM-P-010 — Human Semantic Authority

This human-readable specification is the normative semantic authority for GEDRM 0.1.

Machine-readable artefacts MUST conform to this specification and MUST NOT introduce incompatible semantics.

6. Formal Concept-Kind Taxonomy

GEDRM distinguishes concept family from concept kind. A family groups concepts for navigation and subject matter. A concept kind identifies what sort of thing a concept is ontologically.

The normative concept-kind taxonomy is:

GEDRM Concept
|
+-- 1. Actor / Party
|
+-- 2. Role
|    +-- 2.1 Accountability / Governance Role
|    +-- 2.2 Operational / Data-Flow Role
|    +-- 2.3 Legal / Privacy Role
|
+-- 3. Data Object / Data Asset
|
+-- 4. Data Classification
|    +-- 4.1 Business / Semantic Category
|    +-- 4.2 Provenance Classification
|    +-- 4.3 Legal / Sensitivity Classification
|
+-- 5. Processing / Governance State
|
+-- 6. Data Representation
|
+-- 7. Activity / Process
|
+-- 8. Governed Construct
|    +-- 8.1 Normative Artefact
|    +-- 8.2 Interaction Artefact
|    +-- 8.3 Evaluation Artefact
|    +-- 8.4 Assurance Mechanism
|    +-- 8.5 Assurance Evidence
|    +-- 8.6 Executable Governance Representation
|
+-- 9. Relationship
|
+-- 10. External Traceability Reference

6.1 Actor / Party

An Actor / Party is an entity capable of bearing roles, responsibilities, rights, obligations, or participation in data-related activity. Examples include a legal entity, organization, team, person, public authority, or service provider.

6.2 Role

A Role is a context-dependent function, authority, responsibility, or participation performed by an eligible actor, system, capability, service, or governed construct.

6.3 Data Object / Data Asset

A Data Object is an identifiable body, element, collection, or representation of data that may participate in GEDRM relationships, classification, processing, governance, exchange, or consumption.

6.4 Data Classification

A Data Classification describes a semantic characteristic of data rather than creating a new physical data object.

6.5 Processing / Governance State

A Processing / Governance State describes a governed state reached through processing or stewardship activity.

6.6 Data Representation

A Data Representation is a governed representation of one or more data concepts or entity identities.

6.7 Activity / Process

An Activity / Process is an occurrence or governed activity through which data is processed, derived, mastered, controlled, or otherwise acted upon.

6.8 Governed Construct

A Governed Construct is a governed semantic, normative, interaction, evaluation, assurance, evidence, or executable governance construct.

6.9 Relationship

A Relationship expresses a formal semantic connection between GEDRM concepts.

6.10 External Traceability Reference

An External Traceability Reference allows GEDRM to reference external requirements or authorities without modelling the external requirements domain itself.

7. Concept Families and Registry

7.1 Origin & Authority

ID	Concept	Formal Kind
GEDRM-OA-001	Data Originator	Operational / Data-Flow Role
GEDRM-OA-002	Data Producer	Operational / Data-Flow Role
GEDRM-OA-003	System of Record	Operational / Authority Role
GEDRM-OA-004	Authoritative Source	Operational / Authority Role
GEDRM-OA-005	Data Holder	Rights / Governance Role

7.2 Processing, Provision & Movement

ID	Concept	Formal Kind
GEDRM-PM-001	Data Transformer	Operational / Data-Flow Role
GEDRM-PM-002	Data Transport / Relay	Operational / Data-Flow Role
GEDRM-PM-003	Data Provider	Operational / Data-Flow Role
GEDRM-PM-004	Data Publisher	Operational / Data-Flow Role
GEDRM-PM-005	Data Distributor	Operational / Data-Flow Role
GEDRM-PM-006	Data Broker	Operational / Data-Flow Role

7.3 Data Objects and Products

ID	Concept	Formal Kind
GEDRM-DO-001	Data Object	Data Object
GEDRM-MD-001	Data Asset	Data Object / Data Asset
GEDRM-MD-002	Data Product	Data Object / Data Asset specialization

7.4 Business / Semantic Data Categories

ID	Concept	Formal Kind
GEDRM-DC-001	Master Data	Business / Semantic Classification
GEDRM-DC-002	Reference Data	Business / Semantic Classification
GEDRM-DC-003	Transactional Data	Business / Semantic Classification
GEDRM-DC-004	Market Data	Business / Semantic Classification

7.5 Provenance, State and Representation

ID	Concept	Formal Kind
GEDRM-PC-001	Derived Data	Provenance Classification
GEDRM-GS-001	Mastered	Processing / Governance State
GEDRM-DR-001	Golden Record	Data Representation

7.6 Consumption

ID	Concept	Formal Kind
GEDRM-CO-001	Data Recipient	Operational / Data-Flow Role
GEDRM-CO-002	Data Consumer	Operational / Data-Flow Role

7.7 Governance & Accountability

ID	Concept	Formal Kind
GEDRM-GA-001	Data Owner	Accountability / Governance Role
GEDRM-GA-002	Data Steward	Accountability / Governance Role
GEDRM-GA-003	Data Custodian	Accountability / Governance Role
GEDRM-GA-004	Data Product Owner	Accountability / Governance Role
GEDRM-GA-005	Control Owner	Accountability / Governance Role
GEDRM-GA-006	Source of Authority	Governance / Authority Role or Basis

7.8 Legal / Privacy

ID	Concept	Formal Kind
GEDRM-LP-001	Data Controller	Legal / Privacy Role
GEDRM-LP-002	Data Processor	Legal / Privacy Role
GEDRM-LC-001	Personal Data	Legal / Sensitivity Classification

7.9 Activities

ID	Concept	Formal Kind
GEDRM-AC-001	Processing Activity	Activity / Process
GEDRM-AC-002	Derivation Activity	Activity / Process
GEDRM-AC-003	Mastering Activity	Activity / Process
GEDRM-AC-004	Control Execution	Activity / Process

7.10 Governed Constructs

ID	Concept	Formal Kind
GEDRM-GO-001	Data Policy	Normative Artefact
GEDRM-GO-002	Policy as Code	Executable Governance Representation
GEDRM-GO-003	Data Contract	Interaction Artefact
GEDRM-GO-004	Data Quality Rule	Evaluation Artefact
GEDRM-GO-005	Data Control	Assurance Mechanism
GEDRM-GO-006	Control Evidence	Assurance Evidence

7.11 External Traceability

ID	Concept	Formal Kind
GEDRM-TR-001	Requirement Reference	External Traceability Reference

8. Origin & Authority Concepts

GEDRM-OA-001 — Data Originator

Definition: A party that originally creates data.

Primary question: Where did the data first originate?

Rules:

A Data Originator MAY also be a Data Producer.
Origination does not imply authority, ownership, or authorized distribution.
HDIP ADO, if adopted, is a governed specialization of Data Originator.

GEDRM-OA-002 — Data Producer

Definition: A party or capability that creates, captures, generates, or introduces data into a defined data flow.

Primary question: Who introduces the data into this flow?

Rules:

Data Producer and Data Originator MAY be co-located.
Data Producer and System of Record MAY be co-located.
Production does not by itself establish authority.

GEDRM-OA-003 — System of Record

Definition: A system responsible for maintaining authoritative operational business state for a defined scope.

Primary question: Where is the authoritative business state maintained?

Semantic emphasis: state authority.

Rules:

System of Record authority MUST be scoped.
Different systems MAY be Systems of Record for different lifecycle stages, attributes, or entities.
A System of Record MAY also be an Authoritative Source.
A System of Record need not be the source from which all consumers obtain data.

GEDRM-OA-004 — Authoritative Source

Definition: A source formally recognized as the approved or trusted source from which defined data SHOULD be obtained, validated, or reused for a defined scope or purpose.

Primary question: From where should defined data be obtained or validated?

Semantic emphasis: sourcing authority.

Rules:

Authoritative Source scope MUST be explicit.
An Authoritative Source MAY be the System of Record.
An Authoritative Source MAY be derived from one or more Systems of Record.
A copy MUST NOT be considered authoritative merely because it is widely used.
HDIP ADS is a governed specialization of Authoritative Source.

GEDRM-OA-005 — Data Holder

Definition: A party having legal, contractual, custodial, or equivalent authority sufficient to possess, control, or authorize use or processing of data within a defined context.

Primary question: Who is entitled or responsible to hold or authorize use of the data in this context?

Rules:

Data Holder MUST NOT be assumed equivalent to Data Owner.
Data Holder MUST NOT be assumed equivalent to Data Controller.

9. Processing, Provision & Movement Concepts

GEDRM-PM-001 — Data Transformer

Definition: A party or capability that materially changes data values, structure, semantics, representation, or derivation state.

Primary question: Who or what materially transforms the data?

Rules:

Data Transformer is the generic technical term; GEDRM deliberately avoids Data Processor for this technical role because Data Processor has privacy-law meaning.
A Data Transformer MAY create Derived Data.
Transformation does not establish authority.

GEDRM-PM-002 — Data Transport / Relay

Definition: A party or capability that moves or relays data without materially changing its business meaning.

Primary question: Who or what moves the data?

Rules:

Incidental technical encoding, framing, compression, or transport transformation does not necessarily make the component a Data Transformer.

GEDRM-PM-003 — Data Provider

Definition: A party or capability that makes data available for access, retrieval, receipt, or consumption.

Primary question: Who makes the data available?

Rules:

Provision does not necessarily imply intentional publication, physical distribution, authority, or ownership.

GEDRM-PM-004 — Data Publisher

Definition: A party or capability that intentionally exposes or releases data through a defined publication context, interface, version, contract, policy, or product promise.

Primary question: Who deliberately publishes or releases the data?

Rules:

Publication is stronger than mere availability.
A Data Product output port MAY perform the Data Publisher role.
Publishing data does not automatically make the publisher authoritative for the data.

GEDRM-PM-005 — Data Distributor

Definition: A party or capability responsible for delivering or distributing data from a source, provider, or publisher to permitted recipients or consumers.

Primary question: Who delivers the data?

Rules:

Distribution does not imply source authority.
HDIP ADD is a governed specialization of Data Distributor authorized to distribute a defined data scope to permitted consumers.
Authorized-to-distribute MUST NOT be interpreted as authoritative-for-truth.

GEDRM-PM-006 — Data Broker

Definition: An intermediary that mediates discovery, selection, access, exchange, routing, policy, entitlement, or the provider-consumer relationship without necessarily originating, owning, publishing, or physically delivering the data.

Primary question: Who mediates the data relationship?

Rules:

A technical message broker MUST NOT automatically be classified as a GEDRM Data Broker merely because its product name contains the word broker.
Marketplace and mediation capabilities MAY perform the Data Broker role.

9.1 Provider / Publisher / Distributor / Broker Boundary

Provider    -> makes available
Publisher   -> deliberately exposes/releases
Distributor -> delivers
Broker      -> mediates the relationship

These roles MAY overlap in one implementation while remaining semantically distinct.

10. Data Objects, Assets and Products

GEDRM-DO-001 — Data Object

Definition: An identifiable body, element, collection, or representation of data that may be classified, governed, processed, exchanged, or consumed.

GEDRM permits classification at dataset, entity, record, attribute, field, or derived-output scope where meaningful.

GEDRM-MD-001 — Data Asset

Definition: A Data Object recognized as having actual or potential value and managed accordingly.

Rules:

Not every Data Object must be managed as an enterprise Data Asset.
A Data Asset does not become a Data Product merely because it is useful or widely consumed.

GEDRM-MD-002 — Data Product

Definition: A Data Asset intentionally productized as a governed, reusable, consumable, discoverable, versioned, and accountable product with an explicit product promise and consumer-facing obligations.

Rules:

Data Product is a specialization of Data Asset.
All Data Products are Data Assets; not all Data Assets are Data Products.
Productization is intentional and governance-bearing.
Product-specific obligations MAY be further defined by BPS, HDIP, or domain profiles.

11. Data Classification Model

11.1 Classification Dimensions

GEDRM 0.1 uses a faceted classification model:

Data Object
|
+-- Business / Semantic Category
|    +-- Master Data
|    +-- Reference Data
|    +-- Transactional Data
|    +-- Market Data
|
+-- Provenance Classification
|    +-- Derived Data
|
+-- Processing / Governance State
|    +-- Mastered
|
+-- Legal / Sensitivity Classification
     +-- Personal Data

Overlap across dimensions is intentional.

GEDRM-C-001 — Cross-Dimension Overlap

Data classifications MAY overlap where they belong to different classification dimensions.

GEDRM-C-002 — Semantic Distinction

Business/semantic categories MUST NOT be treated as interchangeable merely because the same physical dataset contains more than one category.

GEDRM-C-003 — Provenance Coexistence

Derived Data MAY also be Master Data, Reference Data, Transactional Data, Market Data, or another semantic category.

GEDRM-C-004 — State Coexistence

Mastered state MAY coexist with applicable semantic, provenance, and legal classifications.

GEDRM-C-005 — Scope

Classification SHOULD be assigned at the smallest meaningful semantic scope.

GEDRM-C-006 — Physical Co-location

Physical co-location of differently classified data MUST NOT imply semantic equivalence.

GEDRM-DC-001 — Master Data

Definition: Data describing core, relatively persistent, identity-bearing business entities that are shared or reused across multiple business processes, transactions, applications, or organizational contexts.

Primary question: Which business thing or entity is this?

Examples include Customer, Party, Product, Supplier, Employee, Location, Account, or Instrument identities where those concepts are managed as core business entities.

Rules:

Identity alone does not make data Master Data.
Master Data MAY contain attributes whose values are Reference Data.
Master Data does not require a specific MDM technology.

GEDRM-DC-002 — Reference Data

Definition: Controlled values, codes, classifications, taxonomies, or enumerations used to classify, constrain, interpret, validate, or consistently describe other data.

Primary question: Which allowed value, type, category, or classification applies?

Examples include currency codes, country codes, payment-purpose codes, lifecycle statuses, product types, asset classes, and controlled classifications.

Rules:

Reference Data MAY be rich, hierarchical, externally standardized, or versioned.
Complexity does not make Reference Data Master Data.
A Master Data entity MAY contain Reference Data attributes.

11.2.1 Master Data vs Reference Data

Master Data    -> identifies the business thing
Reference Data -> classifies, constrains, or interprets the thing

A physical dataset MAY contain both.

GEDRM-DC-003 — Transactional Data

Definition: Data representing or evidencing a discrete business event, activity, exchange, instruction, commitment, or state transition involving one or more business entities, usually with an associated occurrence time and business context.

Primary question: What business activity or state transition happened?

Examples include a payment initiation, trade execution, order, invoice, claim, shipment, account posting, settlement, or service request.

Rules:

Transactional Data is broader than financial transactions.
High volume or frequent change is not definitional.
Transactional Data MAY reference Master Data and use Reference Data.
Transactional Data MAY also be Event Data where another profile defines Event Data.
Derived analytics over transactions are not automatically Transactional Data merely because their inputs were transactional.

GEDRM-DC-004 — Market Data

Definition: Data representing observed, quoted, published, calculated, or otherwise established values describing the state or measurable condition of a market, instrument, benchmark, or financial environment at a defined point or period in time.

Primary question: What is or was the measurable market state?

Examples include prices, rates, fixings, indices, curves, spreads, volatility, liquidity measures, and market observations.

Rules:

Time or effective-period context is commonly material to Market Data.
Change frequency is a characteristic, not the defining criterion.
A market object identifier or controlled classification is not Market Data merely because it relates to markets.
Market Data MAY also be Derived Data.

11.4.1 Market Data vs Reference Data

Reference Data -> describes how a market object is classified or interpreted
Market Data    -> describes the observed or calculated state of that object

Examples:

Example	Classification
`GBP` currency code	Reference Data
`GBP/USD` currency pair definition	Reference Data
`GBP/USD = 1.2742 at time T`	Market Data
SONIA benchmark definition	Reference Data
SONIA fixing for date D	Market Data
`FIXED_INCOME` asset class	Reference Data
bond yield at time T	Market Data

12. Provenance, Processing State and Representation

GEDRM-PC-001 — Derived Data

Definition: Data whose value, structure, classification, or representation is produced from one or more existing data inputs through calculation, transformation, aggregation, inference, enrichment, correlation, reconciliation, or other derivation logic.

Formal kind: Provenance Classification.

Primary question: Was this data produced from other data through derivation?

Rules:

Derived Data is not a peer business/semantic category.
Derived Data MUST have at least one derived-from relationship.
Derived Data MAY also be Market Data, Master Data, Transactional Data, or another semantic category.
Derived Data does not automatically become authoritative.
Derived Data MAY become an Authoritative Source if explicitly governed as such.
Material derivation SHOULD retain lineage to inputs and derivation logic.

12.1.1 Source Data Decision

Source Data is not a first-class intrinsic data category in GEDRM 0.1.

Source-ness is contextual and relational. Data that is derived in one activity may become an input to another activity.

GEDRM therefore represents source context through relationships such as:

is-input-to
derived-from
sourced-from

rather than assigning a permanent Source Data type.

GEDRM-GS-001 — Mastered

Definition: A processing/governance state reached when data has undergone governed matching, identity resolution, reconciliation, standardization, consolidation, survivorship, or equivalent mastering activity.

Formal kind: Processing / Governance State.

Rules:

Mastered is not a business data type.
Mastered MUST NOT be treated as synonymous with Master Data.
Mastered data does not automatically imply a Golden Record.
Mastered data does not automatically imply Authoritative Source status.
Mastered data MAY contain Derived Data attributes.

Human-readable prose MAY use the phrase Mastered Data to mean data in the Mastered state, but the formal ontology SHOULD represent Mastered as a state.

GEDRM-DR-001 — Golden Record

Definition: A governed, reconciled representation of a specific business entity identity produced through mastering and trusted as a preferred enterprise representation for a defined scope.

Formal kind: Data Representation.

Rules:

A Golden Record represents exactly one governed entity identity.
A business entity identity MAY have zero or more Golden Records across different governed scopes.
A Golden Record MAY be physically persisted or virtually assembled.
Golden Record MUST NOT be treated as synonymous with Master Data, Mastered state, System of Record, or Authoritative Source.
A Golden Record MAY be exposed through an Authoritative Source where explicitly governed.

13. Consumption Concepts

GEDRM-CO-001 — Data Recipient

Definition: A party or capability that receives data.

Primary question: Who receives the data?

Receipt does not necessarily imply meaningful use.

GEDRM-CO-002 — Data Consumer

Definition: A party, capability, product, process, or actor that uses data for a defined purpose.

Primary question: Who or what uses the data, and for what purpose?

A Data Consumer MAY also be a Data Recipient, but the roles are not equivalent.

14. Governance, Accountability and Authority

GEDRM-GA-001 — Data Owner

Definition: An accountable governance role responsible for defined data and associated management decisions within a governed scope.

GEDRM-GA-002 — Data Steward

Definition: A governance role responsible for operational stewardship, meaning, quality, issue management, or other delegated governance activities for defined data.

GEDRM-GA-003 — Data Custodian

Definition: A role responsible for technical custody, safeguarding, storage, handling, or operational protection of data.

Data Custodian MUST NOT be assumed equivalent to Data Owner or Data Controller.

GEDRM-GA-004 — Data Product Owner

Definition: An accountable role responsible for the governed lifecycle, product promise, consumer value, and obligations of a Data Product.

GEDRM-GA-005 — Control Owner

Definition: An accountable role responsible for the design, ownership, operation, effectiveness, or governance of a Data Control within a defined scope.

GEDRM-GA-006 — Source of Authority

Definition: A governance actor or normative basis that establishes, recognizes, or mandates which source, value, or representation is authoritative for a defined data scope.

Semantic emphasis: designation or governance authority.

Examples may include a Data Owner, law, regulation, policy, contract, governance body, statutory authority, or architecture decision.

14.6.1 Three-Way Authority Boundary

System of Record    -> authoritative operational state
Authoritative Source -> approved source for obtaining/validating data
Source of Authority  -> establishes or designates authority

These concepts MUST NOT be treated as equivalent.

15. Legal / Privacy Concepts

GEDRM models privacy-law concepts as a distinct legal/privacy family rather than as generic technical data-flow roles.

GEDRM-LP-001 — Data Controller

Definition: A natural or legal person, public authority, agency, or other body that, alone or jointly with others, determines the purposes and essential means of processing Personal Data.

Formal kind: Legal / Privacy Role.

Rules:

The Controller role is contextual to a Processing Activity.
Role assignment MUST follow applicable law and actual functional responsibility rather than contractual label alone.
Data Controller MUST NOT be treated as synonymous with Data Owner or Source of Authority.

GEDRM-LP-002 — Data Processor

Definition: A natural or legal person, public authority, agency, or other body that processes Personal Data on behalf of a Data Controller.

Formal kind: Legal / Privacy Role.

Rules:

The Processor role is contextual to a Processing Activity.
Data Processor MUST NOT be treated as synonymous with Data Transformer or Data Custodian.
A Processor may make implementation decisions while remaining a Processor where it does not determine its own processing purposes and essential means under applicable law.
If a party determines its own purposes and essential means for a processing activity, its legal role MUST be assessed accordingly rather than inferred from contract labels.

15.2.1 Joint Controllers and Sub-processors

GEDRM 0.1 does not require Joint Controller or Sub-processor as separate base classes.

Joint control MAY be represented by multiple Data Controllers related to the same Processing Activity.

Sub-processing MAY be represented by one Data Processor engaging another Data Processor within the relevant Processing Activity and legal context.

GEDRM-LC-001 — Personal Data

Definition: Data classified as personal data under applicable privacy law.

Formal kind: Legal / Sensitivity Classification.

Personal Data is orthogonal to business/semantic categories. For example, a customer record MAY simultaneously be Master Data, Personal Data, and Mastered.

16. Activity / Process Concepts

GEDRM-AC-001 — Processing Activity

Definition: A governed activity in which data is collected, used, transformed, stored, disclosed, combined, analyzed, erased, or otherwise processed.

Processing Activity provides the context in which Data Controller and Data Processor roles are assigned.

Minimal privacy cardinality: where a Processing Activity processes Personal Data and a controller concept is applicable, it MUST have one or more Data Controllers; it MAY have zero or more Data Processors.

GEDRM-AC-002 — Derivation Activity

Definition: An activity that produces Derived Data from one or more data inputs through calculation, transformation, aggregation, inference, enrichment, or related derivation logic.

GEDRM-AC-003 — Mastering Activity

Definition: A governed activity that performs matching, identity resolution, reconciliation, standardization, consolidation, survivorship, or equivalent mastering operations.

GEDRM-AC-004 — Control Execution

Definition: A particular execution, invocation, assessment, or application of a Data Control for a defined scope and time.

Control Execution is distinct from the Data Control definition itself.

17. Governed Constructs

GEDRM-GO-001 — Data Policy

Definition: A governed normative artefact establishing obligations, permissions, prohibitions, principles, or constraints concerning the management, processing, distribution, consumption, protection, lifecycle, or governance of data.

Primary question: What MUST, MAY, or MUST NOT be true?

Rules:

Data Policy MAY exist at enterprise, divisional, domain, regulatory-derived, or product-specific scope.
Data Policy MAY constrain Data Contracts, Data Products, Data Quality Rules, and Data Controls.
Data Policy MUST NOT be treated as synonymous with Policy as Code.

GEDRM-GO-002 — Policy as Code

Definition: An executable representation of one or more resolved and applicable Data Policy obligations.

Primary question: What executable representation implements resolved policy?

Rules:

Policy as Code MUST remain traceable to the governing Data Policy or policies from which it was derived.
Policy as Code MUST NOT be treated as synonymous with Data Policy or Data Control.

GEDRM-GO-003 — Data Contract

Definition: A governed interaction artefact defining semantics, obligations, expectations, interfaces, compatibility conditions, and commitments at a provider, publisher, or Data Product–consumer boundary.

Primary question: What has the provider or product committed to?

A Data Contract MAY include schema, semantics, mandatory attributes, version, compatibility, freshness, completeness, availability, usage, and deprecation commitments.

A Data Contract MAY implement policy-derived obligations but MAY also contain product-promise or consumer commitments not directly derived from policy.

GEDRM-GO-004 — Data Quality Rule

Definition: A governed evaluative artefact defining how a specified data-quality characteristic or condition is measured, determined, or validated.

Primary question: How is the quality condition evaluated?

Rules:

A Data Quality Rule MAY define a formula, predicate, comparison, threshold, or validation condition.
A Data Quality Rule MUST NOT be treated as synonymous with a Data Control.
A metric or threshold is not automatically a Data Control.

GEDRM-GO-005 — Data Control

Definition: A governed assurance mechanism that prevents, detects, corrects, verifies, or evidences whether a policy obligation, rule, contract commitment, product promise, regulatory obligation, or equivalent governed expectation is satisfied.

Primary question: How is the obligation operationally assured, enforced, detected, evidenced, or remediated?

A Data Control normally has a defined objective, trigger or frequency, expected state, rule or threshold, owner, evidence expectations, and failure/exception response.

Rules:

Data Controls MAY be preventive, detective, corrective, or verification-oriented.
Data Controls MAY be automated, manual, or semi-automated.
A Data Quality Control is a subtype or specialization of Data Control that uses Data Quality Rules for quality objectives.
Data Control MUST NOT be treated as synonymous with observability, a dashboard, a metric, Data Policy, or Data Quality Rule.

GEDRM-GO-006 — Control Evidence

Definition: A governed assurance artefact that records, demonstrates, or substantiates the execution, outcome, exception, remediation, approval, or effectiveness of a Data Control for a defined scope and point or period in time.

Primary question: What substantiates that the control operated and what outcome occurred?

Rules:

Control Evidence MUST identify the Data Control it evidences.
Where Control Execution is explicitly modelled, Control Evidence MUST identify the Control Execution it evidences.
Control Evidence MAY represent PASS, FAIL, EXCEPTION, OVERRIDE, PREVENTION, APPROVAL, or REMEDIATION outcomes.
Logs, metrics, observability signals, dashboards, or audit records are not inherently Control Evidence.
Such records MAY contribute to or serve as Control Evidence where they are deliberately governed and sufficient to substantiate a defined control execution or outcome.
Control Evidence MAY itself be managed as a Data Asset where enterprise governance chooses to do so.
Control Evidence does not become a Data Product unless intentionally productized under normal Data Product obligations.

17.6.1 Governed-Construct Boundary

Question	GEDRM Concept
What MUST, MAY, or MUST NOT be true?	Data Policy
What executable representation implements resolved policy?	Policy as Code
What has the provider/product committed to?	Data Contract
How is a quality condition evaluated?	Data Quality Rule
How is an obligation assured, enforced, detected, verified, or remediated?	Data Control
What substantiates control execution and outcome?	Control Evidence

The same concern, such as freshness or completeness, MAY appear across multiple constructs without making them semantically equivalent.

18. External Requirement Traceability

GEDRM-TR-001 — Requirement Reference

Definition: A lightweight reference to an external requirement or source of requirement intent used for traceability from GEDRM governed constructs.

GEDRM 0.1 does not model Data Requirement as a first-class core concept.

Requirements may originate from law, regulation, enterprise policy, programme need, architecture principle, consumer need, contract, product promise, or another external source.

A Requirement Reference MAY carry:

requirement identifier;
source;
version;
authority;
external URI or locator;
effective date or status.

GEDRM relationships MAY express derived-from-requirement, implements-requirement, satisfies-requirement, or evidences-requirement without turning GEDRM into a general requirements-management model.

19. Relationship Registry

ID	Relationship	Meaning
GEDRM-R-001	originates	creates data at its point of origin
GEDRM-R-002	produces	introduces data into a defined flow
GEDRM-R-003	records-authoritative-state-for	maintains authoritative business state for scope
GEDRM-R-004	is-authoritative-source-for	is the approved source for a defined data scope
GEDRM-R-005	transforms	materially transforms or derives data
GEDRM-R-006	transports	moves data without material semantic transformation
GEDRM-R-007	provides	makes data available
GEDRM-R-008	publishes	intentionally exposes or releases data
GEDRM-R-009	distributes	delivers data to recipients or consumers
GEDRM-R-010	brokers / mediates	mediates provider/publisher-consumer interaction
GEDRM-R-011	derived-from	identifies derivation provenance
GEDRM-R-012	is-input-to	identifies contextual input role for an activity
GEDRM-R-013	sourced-from	identifies contextual sourcing relationship
GEDRM-R-014	masters	performs mastering activity
GEDRM-R-015	productizes	promotes/manages a Data Asset as a Data Product
GEDRM-R-016	receives	receives data
GEDRM-R-017	consumes	uses data for a defined purpose
GEDRM-R-018	owns	has accountable governance responsibility
GEDRM-R-019	stewards	performs operational stewardship
GEDRM-R-020	custodians	performs technical custody and safeguarding
GEDRM-R-021	establishes-authority-for	establishes authority for a defined scope
GEDRM-R-022	designates-authoritative-source	designates a source as authoritative
GEDRM-R-023	constrains	applies normative constraint
GEDRM-R-024	represented-as	links a concept to an executable or technical representation
GEDRM-R-025	defines-commitment-for	defines a governed interaction commitment
GEDRM-R-026	evaluates	evaluates a defined condition or characteristic
GEDRM-R-027	assures	assures, enforces, detects, verifies, or remediates an obligation
GEDRM-R-028	plays-role	assigns a contextual role to an eligible bearer
GEDRM-R-029	has-scope	identifies the governed scope of a role, authority, or construct
GEDRM-R-030	determines-purpose-and-means-of	relates a Data Controller to a Processing Activity
GEDRM-R-031	processes-on-behalf-of	relates a Data Processor to a Controller / Processing Activity context
GEDRM-R-032	processes-personal-data	identifies Personal Data processed by an activity
GEDRM-R-033	engages-processor	identifies processor or sub-processor engagement
GEDRM-R-034	instantiates-as	relates a Data Control definition to a Control Execution
GEDRM-R-035	produces-evidence	relates a Data Control or Control Execution to Control Evidence
GEDRM-R-036	evidence-for-control	identifies the Data Control substantiated by Control Evidence
GEDRM-R-037	evidence-for-execution	identifies the Control Execution substantiated by Control Evidence
GEDRM-R-038	derived-from-requirement	traces a governed construct to an external Requirement Reference
GEDRM-R-039	satisfies-requirement	traces satisfaction to an external Requirement Reference

20. Minimal Normative Cardinalities

GEDRM 0.1 defines sparse cardinalities only where needed for semantic validity.

Concept / Relationship	Core Cardinality	Rationale
Authoritative Source → `is-authoritative-source-for`	`1..*`	An Authoritative Source must be authoritative for something
System of Record → `records-authoritative-state-for`	`1..*`	A System of Record must own authoritative state for some scope
Data Product → `hasAccountableOwner`	`1..*`	A product without accountable ownership is not governable
Data Control → `hasControlOwner`	`1..*`	A control requires accountable ownership
Data Control → `produces-evidence`	`0..*`	Evidence instances may depend on execution and retention context
Control Evidence → `evidence-for-control`	`1`	Evidence must identify the control it substantiates
Control Evidence → `evidence-for-execution`	`1` where Control Execution is modelled	Evidence must identify the execution it substantiates
Golden Record → `represents` governed entity identity	`1`	A Golden Record represents one governed entity identity
Data Contract → `defines-commitment-for`	`1..*`	A contract must govern at least one interaction/product/output boundary
Processing Activity → Data Controller	`1..*` where applicable to Personal Data	Supports sole and joint control
Processing Activity → Data Processor	`0..*`	A controller may process directly
Data Processor → `processes-on-behalf-of`	`1..*` within a processor-role context	Processor role is inherently on-behalf-of
Derived Data → `derived-from`	`1..*`	Derived classification requires at least one derivation input

20.1 Cardinality Rule

Exact-cardinality constraints SHOULD be rare in GEDRM core.

Organizational or implementation preferences, such as exactly one Product Owner, belong in HDIP, domain, regulatory, privacy, or enterprise-specific profiles unless semantic validity itself requires the exact count.

21. Non-Equivalence Rules

GEDRM explicitly distinguishes:

Data Originator != Data Producer
Data Producer != System of Record
System of Record != Authoritative Source
System of Record != Source of Authority
Authoritative Source != Source of Authority
Authoritative Source != Data Distributor
Data Transformer != Data Transport / Relay
Data Transformer != Data Processor (privacy-law)
Data Provider != Data Publisher
Data Publisher != Data Distributor
Data Distributor != Data Broker
Data Recipient != Data Consumer
Data Asset != Data Product
Master Data != Reference Data
Master Data != Mastered state
Master Data != Golden Record
Reference Data != Market Data
Transactional Data != Master Data
Transactional Data != Reference Data
Derived Data != business/semantic category
Source Data != first-class intrinsic category
Mastered state != Golden Record
Golden Record != System of Record
Golden Record != Authoritative Source
Data Controller != Data Owner
Data Controller != Source of Authority
Data Processor != Data Transformer
Data Processor != Data Custodian
Data Policy != Policy as Code
Data Policy != Data Contract
Data Policy != Data Control
Data Contract != Data Quality Rule
Data Quality Rule != Data Control
Policy as Code != Data Control
Control Evidence != Data Control
Control Evidence != Data Quality Rule
Control Evidence != generic Metric / Dashboard / Log / Observability Signal

Co-location or shared physical realization MUST NOT erase these semantic distinctions.

22. Core Relationship View

Actor / System / Capability
        |
        | plays-role
        v
Operational / Governance / Legal Role
        |
        +-----------------------------+
        |                             |
        v                             v
Data Object --------------------> Processing Activity
   |                                  |
   | classified-as                    | produces / transforms / controls
   v                                  v
Semantic / Provenance / State      Data Object / Evidence
Classifications

Authority path:
Source of Authority
   -> designates
Authoritative Source
   -> may be fed by
System(s) of Record

Governance path:
Requirement Reference
   -> Data Policy
   -> Policy as Code / Contract / Rule
   -> Data Control
   -> Control Execution
   -> Control Evidence

This view is illustrative rather than a mandatory linear pipeline. Enterprise data architectures are commonly graph-shaped and many-to-many.

23. HDIP Specialization Profile

GEDRM Concept	HDIP Specialization / Mapping	Status
Data Originator	ADO — Authorized Data Originator	Candidate HDIP specialization
Authoritative Source	ADS — Authorized Data Source	HDIP specialization
Data Publisher	HDIP publication capability / Data Product output port	Profile mapping
Data Distributor	ADD — Authorized Data Distributor	HDIP specialization
Data Broker	HDIP marketplace / mediation capability where applicable	Profile mapping
Data Transport / Relay	HDIP gateway / transport capability	Implementation/profile mapping
Data Asset	HDIP governed Data Asset	HDIP specialization
Data Product	HDIP Data Product	HDIP specialization
Data Product Owner	HDIP Data Product Owner	HDIP specialization
Data Policy	HDIP governed policy source	Governance mapping
Policy as Code	Resolved executable policy bundled during PDEP	HDIP runtime specialization
Data Contract	HDIP Data Product / output-port contract	HDIP specialization
Data Quality Rule	HDIP executable DQ rule	HDIP specialization
Data Control	HDIP Data Control	HDIP specialization
Control Evidence	HDIP product/control assurance evidence	HDIP specialization
Productization	HDIP / PDEP-enabled productization	HDIP realization
Strategic Data Platform	HDIP	Architecture realization

23.1 HDIP Authorized Role Rule

The acronyms ADO, ADS, and ADD MUST NOT be represented by GEDRM as universal industry-standard acronyms.

Where used:

ADO is an HDIP specialization of Data Originator;
ADS is an HDIP specialization of Authoritative Source;
ADD is an HDIP specialization of Data Distributor.

23.2 HDIP Data Product Bundle Semantics

During PDEP product development, applicable enterprise, divisional, domain, regulatory-derived, and product-specific policies may be resolved.

Their executable realization MAY be compiled or bound as Policy as Code into a published, versioned Data Product bundle.

The bundle MAY also contain or bind:

Data Contracts;
Data Quality Rules;
Data Controls;
policy and control provenance;
source policy identifiers and versions;
schema and semantics;
lineage and provenance;
observability definitions;
Control Evidence or evidence references.

These constructs remain semantically distinct even when executed in the same product runtime.

At runtime, a product MAY evaluate bundled Policy as Code and execute relevant contracts, rules, and controls locally rather than invoking a central policy service for every already-resolved policy decision. Central or federated policy services remain relevant for authoring, lifecycle, applicability, approval, versioning, and change propagation.

24. Example Instantiation — Payment Domain

24.1 Role and Classification Mapping

Corporate Client
  <<Data Originator>>

Payment Initiation Service
  <<Data Producer>>
  <<System of Record for Payment Instruction state>>

Payment Initiation ADS
  <<Authoritative Source>>
  <<HDIP ADS>>

Payment Processor
  <<Data Transformer>>
  <<System of Record for Processing State>>

Payment Gateway
  <<Data Transport / Relay>>

PTDS / TDS
  <<Data Transformer>>
  <<Data Provider>>
  <<possible Publisher / ADS / ADD only where explicitly governed>>

Foundation Payment Lifecycle Data Product
  <<Data Product>>
  <<Data Publisher through governed output ports>>

Payment instruction / lifecycle events
  <<Transactional Data>>

Currency code / payment purpose / status code
  <<Reference Data>>

Customer / Account / Instrument identity
  <<Master Data where governed as core business entities>>

Regulatory Reporting
  <<Data Consumer>>

24.2 Market / Reference Example

GBP                         -> Reference Data
GBP/USD pair definition     -> Reference Data
GBP/USD = 1.2742 at time T  -> Market Data
Calculated forward FX rate  -> Market Data + Derived Data

24.3 Completeness Governance Example

Data Policy

Critical payment lifecycle data MUST contain the mandatory business attributes required for its intended operational and regulatory use.

Data Contract

The Payment Lifecycle Data Product output port guarantees that paymentId, debtorAccount, creditorAccount, amount, currency, and paymentStatus are populated for at least 99.95% of in-scope published records.

Data Quality Rule

completeness = records_with_all_required_fields / total_in_scope_records
completeness >= 99.95%

Data Control

Evaluate the completeness rule every five minutes over the current publication window. On breach, create evidence, mark the product/output degraded where appropriate, notify the accountable owner, apply the defined publication or regulatory-use restriction, and initiate remediation.

Control Evidence

controlId = CTRL-PAY-COMP-001
controlExecutionId = CE-20260908-1005
productVersion = FPLDP-14
ruleVersion = DQ-COMP-5
populationSize = ...
observedCompleteness = 99.91%
threshold = 99.95%
outcome = FAIL
evaluatedAt = ...
exceptionId = ...
remediationId = ...

This preserves:

Policy   -> obligation
Contract -> commitment
DQ Rule  -> evaluation logic
Control  -> operational assurance
Evidence -> substantiation of execution/outcome

24.4 Privacy Example

Bank
  <<Data Controller for Customer KYC Processing Activity>>

Cloud / managed service provider
  <<Data Processor for that Processing Activity where legally applicable>>

Customer identity data
  <<Master Data>>
  <<Personal Data>>
  <<Mastered, if governed mastering has occurred>>

Legal/privacy role assignment remains contextual to the Processing Activity and applicable law.

25. Conformance

An architecture conforms to GEDRM 0.1 when it:

uses GEDRM concepts with materially consistent meanings;
identifies authority scope explicitly where authority is represented;
preserves the distinction between state authority, sourcing authority, and designation authority;
does not equate logically distinct roles because they are co-located;
distinguishes Data Assets from Data Products;
uses the faceted classification model consistently;
does not model Source Data as an intrinsic peer category where a contextual relationship is sufficient;
represents Mastered as a processing/governance state rather than a peer business data type;
distinguishes Golden Record from Master Data, Mastered state, System of Record, and Authoritative Source;
distinguishes privacy-law Data Processor from technical Data Transformer;
preserves the semantic distinction among Data Policy, Policy as Code, Data Contract, Data Quality Rule, Data Control, and Control Evidence;
treats Data Requirement as external traceability in GEDRM 0.1 rather than a core governed construct;
applies only the core cardinalities relevant to its scope;
documents local terminology mappings, extensions, and specializations;
ensures machine-readable representations remain compatible with the normative human-readable semantics.

A conforming architecture MAY omit concepts not applicable to its scope.

26. Extension and Profile Model

GEDRM MAY be extended through explicit profiles, including:

HDIP Profile;
Privacy Profile;
Payments Profile;
Banking Profile;
Regulatory Profile;
Healthcare Profile;
Telecom Profile;
enterprise-specific profiles.

A profile MAY:

add specialized concepts;
add relationships;
add controlled vocabulary;
tighten SHACL constraints;
add domain-specific semantics consistent with the core;
provide implementation mappings.

A profile MUST NOT redefine the normative meaning of a core GEDRM concept while claiming conformance to that concept.

27. Machine-Readable Representation

GEDRM 0.1 supports companion machine-readable representations using JSON-LD, RDF/OWL, and SHACL.

27.1 Normative Precedence

The human-readable GEDRM specification is the normative semantic authority.

Machine-readable artefacts encode or validate the specification; they do not independently redefine it.

27.2 JSON-LD

JSON-LD provides:

canonical terms and IRIs;
JSON graph interoperability;
a compact developer-facing vocabulary mapping.

JSON-LD SHOULD NOT introduce business semantics absent from the normative specification.

27.3 RDF / OWL

RDF/OWL SHOULD encode:

classes;
subclass relationships;
object properties;
datatype properties;
formally agreed semantic relationships;
carefully selected semantic restrictions.

OWL disjointness MUST be used only where ontological impossibility has been explicitly agreed.

Different classification dimensions MUST NOT be made disjoint merely because they are conceptually distinct.

27.4 SHACL

SHACL is the primary mechanism for expressing practical conformance constraints, including minimal cardinalities.

GEDRM core SHACL SHOULD remain sparse.

Profiles MAY tighten constraints. For example:

GEDRM Core:
  Data Product hasAccountableOwner minCount 1

HDIP Profile:
  Data Product hasProductOwner minCount 1
  Data Product hasProductOwner maxCount 1

where the profile intentionally adopts a stricter operating rule.

27.5 Role Assignment and Scope Pattern

Context-sensitive roles SHOULD support explicit role assignment and scope in machine-readable representations.

For example:

System X
  -> playsRole -> SystemOfRecordAssignment
  -> hasScope  -> PaymentInstructionState

and:

Bank
  -> playsRole -> DataControllerAssignment
  -> hasScope  -> CustomerKYCProcessingActivity

This is preferred to treating every contextual role as an intrinsic global type of the actor or system.

27.6 Stable Namespace and Versioning

GEDRM SHOULD use stable concept IRIs and versioned ontology documents.

Concept identity SHOULD remain stable across backward-compatible versions while ontology metadata identifies the release version.

27.7 GEDRM 0.1 Artefact Set

GEDRM 0.1 separates the human-readable normative specification from its machine-readable publication artefacts.

The human-readable specification is maintained under the documentation tree, while machine-readable artefacts are published from:

BPS/static/spec/gedrm/0.1/

At runtime, Docusaurus publishes files beneath static/ from the site root. The public GEDRM 0.1 machine-readable base path is therefore:

/spec/gedrm/0.1/

The current 0.1 artefact set is:

gedrm-0.1.concept-registry.yaml
gedrm-0.1.context.jsonld
gedrm-0.1.schema.json
gedrm-0.1.ttl
gedrm-0.1.shacl.ttl
examples/
testcases/

The concept registry MAY act as a controlled machine-readable source for canonical IDs, names, kinds, definitions, status, parent concepts, relationships, and references, but it MUST remain semantically consistent with this specification.

27.7.1 Validation Responsibility

The artefacts have distinct responsibilities:

gedrm-0.1.context.jsonld defines compact JSON-LD terms and canonical IRI mappings;
gedrm-0.1.ttl encodes the RDF/OWL ontology;
gedrm-0.1.shacl.ttl expresses the core semantic conformance constraints;
gedrm-0.1.schema.json provides structural JSON / JSON-LD validation;
examples/ provides illustrative GEDRM instances;
testcases/ provides valid and invalid conformance cases and the automated conformance runner.

JSON Schema MUST NOT be treated as a substitute for GEDRM semantic conformance. SHACL remains the primary machine-readable semantic conformance layer.

27.8 Downloads

The following GEDRM 0.1 machine-readable artefacts are published directly from the BPS Docusaurus static/spec/gedrm/0.1/ directory.

Artefact	Purpose	Download
Concept Registry	Canonical machine-readable registry of GEDRM concepts, kinds, relationships, mappings, and constraints	Download YAML
JSON-LD Context	Compact terms and canonical IRI mappings for GEDRM JSON-LD	Download JSON-LD
JSON Schema	Structural JSON / JSON-LD validation companion	Download JSON Schema
RDF/OWL Ontology	Formal GEDRM ontology and relationship vocabulary	Download Turtle
SHACL Shapes	Core GEDRM semantic conformance constraints	Download SHACL
Testcase Manifest	Inventory of valid, invalid, and structural conformance cases	Download Manifest
Conformance Runner	Automated GEDRM 0.1 schema / RDF / SHACL conformance runner	Download Runner
Conformance Requirements	Python dependencies for the conformance runner	Download Requirements

Illustrative examples are also published directly beneath /spec/gedrm/0.1/examples/, including:

The human-readable specification remains the normative semantic authority even where a machine-readable artefact is downloadable.

28. Relationship to GEDRA

GEDRM defines:

concepts;
formal concept kinds;
semantic distinctions;
relationship vocabulary;
classification dimensions;
governance/accountability semantics;
legal/privacy role placement;
minimal conformance semantics.

GEDRA defines:

architectural planes;
structural arrangement;
cross-cutting concerns;
reusable architecture patterns;
architecture views;
derivation guidance.

GEDRM
  concepts + semantics
        |
        v
GEDRA
  reusable architectural structure
        |
        v
Enterprise / Domain Data Architecture
        |
        v
Programme / Solution Data Architecture

GEDRA SHOULD use GEDRM as its canonical conceptual vocabulary.

29. Relationship to HDIP, BPS, UPOS, ProductVerse and AIPS

GEDRM is independently usable as a generic enterprise data reference model.

It is also designed to align with:

BPS — universal product grammar and product constructs;
UPOS — universal productization architecture;
ProductVerse — interconnected product relationship models;
HDIP — strategic Data & AI architecture that specializes and realizes GEDRM concepts;
AIPS — AI Product-specific productization and governance requirements.

GEDRM provides generic data semantics beneath those specializations rather than redefining their product-specific concerns.

30. Versioning and Deprecation

GEDRM uses a MAJOR.MINOR version convention.

0.1 — initial normative draft baseline;
0.2 — backward-compatible refinement/addition;
1.0 — first stable baseline;
2.0 — materially incompatible semantic revision.

Published normative content SHOULD remain immutable once superseded except for clearly identified errata.

Deprecated concepts SHOULD carry:

Status: Deprecated
Deprecated Since: x.y
Replacement: GEDRM-...
Reason: ...

31. Reference Source Register

GEDRM distinguishes externally grounded terminology, established industry usage, GEDRM-defined framing, and HDIP-specific specialization.

Ref ID	Concept / Term	Source / Basis	GEDRM Treatment
GEDRM-REF-001	Data Originator	ISO/IEC-aligned terminology	Generic external term
GEDRM-REF-002	Data Holder	ISO/IEC-aligned terminology	Generic external term
GEDRM-REF-003	Data Owner	ISO/IEC-aligned and broad Data Governance usage	Generic external term
GEDRM-REF-004	System of Record	Established enterprise information-systems terminology	Generic industry term
GEDRM-REF-005	Authoritative Source	NIST and government/enterprise architecture terminology	Generic external term
GEDRM-REF-006	Data Custodian	Government and broad Data Governance usage	Generic external term
GEDRM-REF-007	Golden Record	Established Master Data Management terminology	Generic industry term
GEDRM-REF-008	Data Controller / Data Processor	GDPR / UK GDPR privacy-law terminology and regulatory guidance	Legal/privacy profile concepts
GEDRM-REF-009	Data Product	Established contemporary data-product terminology; GEDRM applies explicit productization semantics	Generic concept with GEDRM framing
GEDRM-REF-010	ADS — Authorized Data Source	HDIP	HDIP specialization of Authoritative Source
GEDRM-REF-011	ADD — Authorized Data Distributor	HDIP	HDIP specialization of Data Distributor
GEDRM-REF-012	ADO — Authorized Data Originator	HDIP candidate term	HDIP specialization of Data Originator if adopted

Exact bibliographic references and URIs SHOULD be maintained in the published documentation bundle as the source register is hardened toward GEDRM 1.0.

32. Governing Statement

GEDRM defines reusable enterprise data semantics independently of the systems and technologies that realize them.

GEDRM does not force every enterprise into one implementation topology or operating model.

Its purpose is to ensure that when architects discuss data origin, authority, processing, provision, productization, classification, provenance, mastering, privacy, governance, control, and evidence, those concepts have stable, explicit, and distinguishable meanings.

Appendix A — Compact Concept Registry

ID	Concept	Formal Kind	HDIP / Profile Mapping
GEDRM-OA-001	Data Originator	Operational Role	ADO candidate
GEDRM-OA-002	Data Producer	Operational Role	—
GEDRM-OA-003	System of Record	Authority Role	—
GEDRM-OA-004	Authoritative Source	Authority Role	ADS
GEDRM-OA-005	Data Holder	Rights / Governance Role	—
GEDRM-PM-001	Data Transformer	Operational Role	—
GEDRM-PM-002	Data Transport / Relay	Operational Role	Gateway / transport
GEDRM-PM-003	Data Provider	Operational Role	—
GEDRM-PM-004	Data Publisher	Operational Role	Output-port publication
GEDRM-PM-005	Data Distributor	Operational Role	ADD
GEDRM-PM-006	Data Broker	Operational Role	Marketplace / mediation
GEDRM-DO-001	Data Object	Data Object	—
GEDRM-MD-001	Data Asset	Data Asset	HDIP Data Asset
GEDRM-MD-002	Data Product	Data Asset specialization	HDIP Data Product
GEDRM-DC-001	Master Data	Business/Semantic Classification	—
GEDRM-DC-002	Reference Data	Business/Semantic Classification	—
GEDRM-DC-003	Transactional Data	Business/Semantic Classification	—
GEDRM-DC-004	Market Data	Business/Semantic Classification	—
GEDRM-PC-001	Derived Data	Provenance Classification	—
GEDRM-GS-001	Mastered	Processing/Governance State	—
GEDRM-DR-001	Golden Record	Data Representation	—
GEDRM-CO-001	Data Recipient	Operational Role	—
GEDRM-CO-002	Data Consumer	Operational Role	—
GEDRM-GA-001	Data Owner	Accountability Role	—
GEDRM-GA-002	Data Steward	Accountability Role	—
GEDRM-GA-003	Data Custodian	Accountability Role	—
GEDRM-GA-004	Data Product Owner	Accountability Role	HDIP Data Product Owner
GEDRM-GA-005	Control Owner	Accountability Role	HDIP / enterprise control model
GEDRM-GA-006	Source of Authority	Governance / Authority Role or Basis	—
GEDRM-LP-001	Data Controller	Legal/Privacy Role	Privacy profile
GEDRM-LP-002	Data Processor	Legal/Privacy Role	Privacy profile
GEDRM-LC-001	Personal Data	Legal/Sensitivity Classification	Privacy profile
GEDRM-AC-001	Processing Activity	Activity / Process	Privacy profile
GEDRM-AC-002	Derivation Activity	Activity / Process	—
GEDRM-AC-003	Mastering Activity	Activity / Process	—
GEDRM-AC-004	Control Execution	Activity / Process	Assurance profile
GEDRM-GO-001	Data Policy	Normative Artefact	HDIP governed policy source
GEDRM-GO-002	Policy as Code	Executable Governance Representation	Bundled executable policy
GEDRM-GO-003	Data Contract	Interaction Artefact	HDIP product/output-port contract
GEDRM-GO-004	Data Quality Rule	Evaluation Artefact	HDIP executable DQ rule
GEDRM-GO-005	Data Control	Assurance Mechanism	HDIP Data Control
GEDRM-GO-006	Control Evidence	Assurance Evidence	HDIP assurance evidence
GEDRM-TR-001	Requirement Reference	External Traceability Reference	External requirements mapping

Appendix B — Semantic-Lock Register

Topic	GEDRM 0.1 Locked Decision
Reference Data vs Master Data	Distinct business/semantic categories: business entity identity vs controlled classification/value
Market Data vs Reference Data	Market state/measurement vs semantic classification/controlled value
Transactional Data	First-class business/semantic category for discrete business events, activities, exchanges, instructions, commitments, or state transitions
Derived Data	Provenance classification, not peer business category
Source Data	Not a first-class intrinsic category; represented relationally/contextually
Mastered Data	Formalized as `Mastered` processing/governance state, not peer data type
Classification overlap	Allowed across orthogonal dimensions; expressed through faceted classification
Data Controller / Processor	First-class Legal/Privacy Roles contextual to Processing Activity
Personal Data	Orthogonal Legal/Sensitivity Classification
Control Evidence	First-class Assurance Evidence concept
Data Requirement	External/reference traceability only in 0.1
Cardinalities	Sparse, semantics-driven core constraints; stricter profiles allowed
Concept-kind taxonomy	Normative in 0.1
Machine-readable representation	JSON-LD + RDF/OWL + SHACL companion formalization; human spec remains normative

Appendix C — Deferred / Future Refinement

The semantic-lock topics targeted for GEDRM 0.1 are complete.

Future versions MAY refine or extend, without reopening the locked 0.1 meanings unless a versioned semantic change is explicitly approved:

richer legal/privacy roles such as Data Subject as a first-class concept;
explicit Joint Controller and Sub-processor modelling patterns where useful;
broader event-data classification;
additional legal/sensitivity classifications;
detailed control taxonomy and control-effectiveness modelling;
exact bibliographic/URI hardening of the reference source register;
domain-specific cardinalities through profiles;
expanded ontology alignment with external standards and vocabularies;
CI workflow integration for the GEDRM conformance runner, so schema / RDF / SHACL regression checks execute automatically on relevant specification changes. This is intentionally deferred until the 0.1 machine-readable baseline and repository workflow conventions are stabilized.

1. Specification Identity​

1.1 Version Identifier​

1.2 Semantic-Lock Status​

2. Purpose​

3. Scope​

4. Normative Language​

5. Core Modelling Principles

GEDRM-P-001 — Technology Independence​

GEDRM-P-002 — Role / Realizer Separation​

GEDRM-P-003 — Role Co-location​

GEDRM-P-004 — Scoped Authority​

GEDRM-P-005 — Authoritative vs Authorized​

GEDRM-P-006 — Faceted Classification​

GEDRM-P-007 — Smallest Meaningful Scope​

GEDRM-P-008 — Explicit Specialization​

GEDRM-P-009 — Semantic Necessity Cardinality​

GEDRM-P-010 — Human Semantic Authority​

6. Formal Concept-Kind Taxonomy

6.1 Actor / Party​

6.2 Role​

6.3 Data Object / Data Asset​

6.4 Data Classification​

6.5 Processing / Governance State​

6.6 Data Representation​

6.7 Activity / Process​

6.8 Governed Construct​

6.9 Relationship​

6.10 External Traceability Reference​

7. Concept Families and Registry

7.1 Origin & Authority​

7.2 Processing, Provision & Movement​

7.3 Data Objects and Products​

7.4 Business / Semantic Data Categories​

7.5 Provenance, State and Representation​

7.6 Consumption​

7.7 Governance & Accountability​

7.8 Legal / Privacy​

7.9 Activities​

7.10 Governed Constructs​

7.11 External Traceability​

8. Origin & Authority Concepts

GEDRM-OA-001 — Data Originator​

GEDRM-OA-002 — Data Producer​

GEDRM-OA-003 — System of Record​

GEDRM-OA-004 — Authoritative Source​

GEDRM-OA-005 — Data Holder​

9. Processing, Provision & Movement Concepts

GEDRM-PM-001 — Data Transformer​

GEDRM-PM-002 — Data Transport / Relay​

GEDRM-PM-003 — Data Provider​

GEDRM-PM-004 — Data Publisher​

GEDRM-PM-005 — Data Distributor​

GEDRM-PM-006 — Data Broker​

9.1 Provider / Publisher / Distributor / Broker Boundary​

10. Data Objects, Assets and Products

GEDRM-DO-001 — Data Object​

GEDRM-MD-001 — Data Asset​

GEDRM-MD-002 — Data Product​

11. Data Classification Model

11.1 Classification Dimensions​

GEDRM-C-001 — Cross-Dimension Overlap​

GEDRM-C-002 — Semantic Distinction​

GEDRM-C-003 — Provenance Coexistence​

GEDRM-C-004 — State Coexistence​

GEDRM-C-005 — Scope​

GEDRM-C-006 — Physical Co-location​

GEDRM-DC-001 — Master Data​

GEDRM-DC-002 — Reference Data​

11.2.1 Master Data vs Reference Data​

GEDRM-DC-003 — Transactional Data​

GEDRM-DC-004 — Market Data​

11.4.1 Market Data vs Reference Data​

12. Provenance, Processing State and Representation

GEDRM-PC-001 — Derived Data​

12.1.1 Source Data Decision​

GEDRM-GS-001 — Mastered​

GEDRM-DR-001 — Golden Record​

13. Consumption Concepts

GEDRM-CO-001 — Data Recipient​

GEDRM-CO-002 — Data Consumer​

1. Specification Identity

1.1 Version Identifier

1.2 Semantic-Lock Status

2. Purpose

3. Scope

4. Normative Language

GEDRM-P-001 — Technology Independence

GEDRM-P-002 — Role / Realizer Separation

GEDRM-P-003 — Role Co-location

GEDRM-P-004 — Scoped Authority

GEDRM-P-005 — Authoritative vs Authorized

GEDRM-P-006 — Faceted Classification

GEDRM-P-007 — Smallest Meaningful Scope

GEDRM-P-008 — Explicit Specialization

GEDRM-P-009 — Semantic Necessity Cardinality

GEDRM-P-010 — Human Semantic Authority

6.1 Actor / Party

6.2 Role

6.3 Data Object / Data Asset

6.4 Data Classification

6.5 Processing / Governance State

6.6 Data Representation

6.7 Activity / Process

6.8 Governed Construct

6.9 Relationship

6.10 External Traceability Reference

7.1 Origin & Authority

7.2 Processing, Provision & Movement

7.3 Data Objects and Products

7.4 Business / Semantic Data Categories

7.5 Provenance, State and Representation

7.6 Consumption

7.7 Governance & Accountability

7.8 Legal / Privacy

7.9 Activities

7.10 Governed Constructs

7.11 External Traceability

GEDRM-OA-001 — Data Originator

GEDRM-OA-002 — Data Producer

GEDRM-OA-003 — System of Record

GEDRM-OA-004 — Authoritative Source

GEDRM-OA-005 — Data Holder

GEDRM-PM-001 — Data Transformer

GEDRM-PM-002 — Data Transport / Relay

GEDRM-PM-003 — Data Provider

GEDRM-PM-004 — Data Publisher

GEDRM-PM-005 — Data Distributor

GEDRM-PM-006 — Data Broker

9.1 Provider / Publisher / Distributor / Broker Boundary

GEDRM-DO-001 — Data Object

GEDRM-MD-001 — Data Asset

GEDRM-MD-002 — Data Product

11.1 Classification Dimensions

GEDRM-C-001 — Cross-Dimension Overlap

GEDRM-C-002 — Semantic Distinction

GEDRM-C-003 — Provenance Coexistence

GEDRM-C-004 — State Coexistence

GEDRM-C-005 — Scope

GEDRM-C-006 — Physical Co-location

GEDRM-DC-001 — Master Data

GEDRM-DC-002 — Reference Data

11.2.1 Master Data vs Reference Data

GEDRM-DC-003 — Transactional Data

GEDRM-DC-004 — Market Data

11.4.1 Market Data vs Reference Data

GEDRM-PC-001 — Derived Data

12.1.1 Source Data Decision

GEDRM-GS-001 — Mastered

GEDRM-DR-001 — Golden Record

GEDRM-CO-001 — Data Recipient

GEDRM-CO-002 — Data Consumer

GEDRM-GA-001 — Data Owner

GEDRM-GA-002 — Data Steward

GEDRM-GA-003 — Data Custodian

GEDRM-GA-004 — Data Product Owner

GEDRM-GA-005 — Control Owner

GEDRM-GA-006 — Source of Authority

14.6.1 Three-Way Authority Boundary

GEDRM-LP-001 — Data Controller

GEDRM-LP-002 — Data Processor