GEDRA 0.1 — Generic Enterprise Data Reference Architecture

Status: Normative Release Candidate
Version: 0.1
Specification Family: GEDRA — Generic Enterprise Data Reference Architecture
Semantic Foundation: GEDRM 0.1
Repository Target: BPS/static/specs/gedra/0.1/
Published Docusaurus Base Path: /specs/gedra/0.1/

1. Purpose

GEDRA defines a reusable, technology-agnostic enterprise data reference architecture for structuring how data meaning, authority, processing, provision, productization, governance, consumption, observability, and lifecycle responsibilities are organized across an enterprise.

GEDRA provides a common architectural frame from which enterprise, divisional, domain, programme, and solution data architectures can be derived.

GEDRA does not prescribe one implementation topology, vendor stack, operating model, or deployment model.

GEDRA uses GEDRM 0.1 as its canonical semantic vocabulary.

2. Scope

GEDRA 0.1 defines:

architectural planes and their responsibilities;
architectural boundaries between data roles and concerns;
cross-cutting governance and control responsibilities;
a technology / utility foundation boundary;
mapping of GEDRM concepts into architectural viewpoints;
reusable enterprise data architecture patterns;
architectural interaction and flow patterns;
reference views for enterprise and domain architecture;
derivation guidance for programme and solution architectures;
conformance expectations for architectures claiming GEDRA alignment;
profile and specialization hooks, including HDIP.

GEDRA 0.1 does not:

redefine GEDRM concepts or semantics;
define application architecture;
define technology architecture;
prescribe products, vendors, cloud platforms, or runtime services;
require each architectural plane to be implemented by a separate system;
require a linear data flow;
make HDIP-specific roles such as ADS or ADD generic GEDRA concepts;
replace enterprise data management requirements or controls.

3. Relationship to GEDRM

GEDRM defines the semantic vocabulary used by GEDRA.

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

GEDRA defines architectural planes, structural arrangement, cross-cutting concerns, reusable patterns, architecture views, and derivation guidance.

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

GEDRA MUST NOT redefine a GEDRM concept incompatibly.

Where GEDRA requires a concept not present in GEDRM, it MUST determine whether that concept is architectural in nature or semantic in nature. Architectural concepts belong in GEDRA; semantic concepts SHOULD be recorded as candidate GEDRM extensions rather than silently introduced.

4. Architectural Principles

4.1 Data Architecture Is Role-Based, Not Application-Centric

GEDRA models data responsibilities, authority, semantics, processing, provision, governance, productization, and consumption independently of application boundaries.

A single application, platform, service, or capability MAY perform roles spanning multiple GEDRA planes.

A GEDRA plane MUST NOT be interpreted as requiring a separate system.

4.2 Authority Is Scoped

Authority MUST be explicit for a defined data scope.

Authority MAY vary by entity, attribute, lifecycle stage, jurisdiction, legal basis, business capability, time period, or governed purpose.

4.3 Meaning Precedes Movement

Data semantics, business meaning, classification, and relationship context SHOULD be explicit independently of transport or storage technology.

Moving data does not establish meaning or authority.

4.4 Processing Does Not Establish Authority

Transformation, derivation, enrichment, aggregation, mastering, or distribution MUST NOT by themselves establish authoritative status.

Derived data MAY become authoritative only through explicit governance and designation.

4.5 Productization Is Intentional

A Data Asset does not become a Data Product merely because it is valuable, reusable, widely consumed, or technically exposed.

Productization requires intentional acceptance of product obligations.

4.6 Governance and Control Are Cross-Cutting

Governance, policy, security, privacy, quality, lineage, lifecycle, controls, evidence, and accountability apply across the data lifecycle and MUST NOT be modeled merely as a downstream stage.

4.7 Consumption Shapes Architectural Obligations

Consumer classes and intended use influence required quality, latency, lineage, support, resilience, compatibility, lifecycle, access, and productization obligations.

4.8 Architecture Is Often Graph-Shaped

GEDRA permits many-to-many and non-linear relationships.

The common progression from semantics through authority, processing, productization, consumption, and feedback is a reference view, not a mandatory execution pipeline.

4.9 Technology Enables but Does Not Define Data Architecture

Compute, storage, networking, IAM, messaging, runtime platforms, orchestration, CI/CD, resilience, and hosting are enabling capabilities.

They are not, by themselves, the enterprise data architecture.

4.10 Reference Architecture Must Be Derivable

GEDRA SHOULD be sufficiently abstract to apply across enterprises, while sufficiently explicit that concrete architectures can be derived from it.

5. Architectural Meta-Model

Diagram

GEDRA 0.1 defines the following top-level architectural constructs:

GEDRA
|
+-- Architectural Plane
|   +-- Semantic & Enterprise Ontology Plane
|   +-- Authority Plane
|   +-- Processing, Provision & Movement Plane
|   +-- Data Platform & Product Plane
|   +-- Consumption & Access Plane
|   +-- Value, Observability & Feedback Plane
|
+-- Cross-Cutting Governance & Control
|
+-- Technology / Utility Foundation
|
+-- Architecture Pattern
|
+-- Architecture View
|
+-- Profile / Specialization

5.1 Architectural Plane

An Architectural Plane is a logical architectural viewpoint grouping related responsibilities, roles, and concerns.

A plane is not an application silo, is not necessarily a deployment boundary, MAY be realized by multiple capabilities, MAY overlap implementation-wise with other planes, and groups architectural responsibilities rather than products or technologies.

5.2 Cross-Cutting Governance & Control

Represents obligations and assurance responsibilities applying across all planes, including ownership, stewardship, classification, policy, privacy, access, contracts, versioning, metadata, lineage, quality, retention, residency, security, observability, economic accountability, lifecycle, Data Controls, and Control Evidence.

5.3 Technology / Utility Foundation

Represents enabling infrastructure and platform capabilities required to realize GEDRA-aligned architectures, including compute, storage, networking, IAM, messaging, CI/CD, hosting, resilience, runtime, and orchestration.

Technology capabilities MUST NOT be used as substitutes for GEDRA semantic or architectural roles.

5.4 Architecture Pattern

A reusable arrangement of GEDRA concepts, planes, responsibilities, and interactions addressing a recurring enterprise data architecture problem.

Expected 0.1 patterns include scoped authority, authoritative sourcing, derivation, governed distribution, productization, policy-to-control-to-evidence, privacy processing-role, consumer access, and feedback/product evolution.

5.5 Architecture View

A projection of GEDRA for a defined stakeholder concern.

Expected views include overview/plane, authority, processing/provision/movement, data product, governance/assurance, consumer, privacy, and HDIP specialization.

5.6 Profile / Specialization

A GEDRA Profile specializes the generic reference architecture for a specific enterprise, domain, regulatory context, platform, or operating model.

A profile MAY add stricter constraints, implementation-specific capabilities, generic-to-platform role mappings, and domain-specific patterns, but MUST NOT redefine GEDRM or GEDRA core semantics incompatibly.

6. Initial Plane Set

GEDRA 0.1 adopts the following initial planes:

Semantic & Enterprise Ontology Plane — defines business meaning, shared vocabulary, classifications, and semantic relationships.
Authority Plane — establishes origin, state authority, sourcing authority, and designation of authority for governed data scopes.
Processing, Provision & Movement Plane — transforms, derives, transports, provides, publishes, distributes, and mediates data.
Data Platform & Product Plane — provides governed persistence, management, metadata, quality, lineage, discovery, and productization capabilities.
Consumption & Access Plane — represents consumers, recipients, discovery, access, entitlement, and consumption modes.
Value, Observability & Feedback Plane — captures usage, cost, value, operational signals, feedback, and product evolution.

These planes are logical architectural viewpoints and not mandatory physical tiers.

6.1 Semantic & Enterprise Ontology Plane

6.1.1 Purpose

The Semantic & Enterprise Ontology Plane establishes the governed business meaning of data independently of the systems, stores, interfaces, products, and technologies that realize or transport it.

Its purpose is to ensure that enterprise data can be interpreted consistently across organizational, domain, application, product, analytical, regulatory, and AI contexts.

This plane answers questions such as:

What business concept does this data represent?
What is the identity of the business thing being described?
How are concepts related?
Which terms are synonymous, narrower, broader, equivalent, or explicitly different?
Which controlled classifications or vocabularies constrain valid values?
Which semantic definition applies to an attribute, entity, event, measure, state, or relationship?
Which external or industry standard does an enterprise concept map to?
What semantic meaning must remain stable as data moves between systems or products?

The plane SHOULD provide the semantic foundation consumed by all other GEDRA planes.

6.1.2 Architectural Responsibility

The Semantic & Enterprise Ontology Plane is responsible for the architectural treatment of:

canonical business concepts;
enterprise and domain entities;
semantic relationships;
role semantics;
taxonomies and controlled vocabularies;
business definitions;
semantic classifications;
canonical attribute meaning;
critical data element semantics where adopted;
mappings between enterprise concepts and external standards;
semantic identifiers and aliases;
semantic lineage or mapping between representations;
semantic compatibility across producers, products, contracts, and consumers;
governed evolution of shared meaning.

The plane SHOULD enable multiple physical representations to be recognized as representing the same governed business concept without requiring those representations to be physically identical.

6.1.3 Relationship to GEDRM

GEDRM provides the canonical semantic vocabulary used by this plane.

The plane MUST distinguish between:

GEDRM reference-model semantics, which define reusable enterprise data concepts such as Data Product, Authoritative Source, Data Consumer, Master Data, Reference Data, Derived Data, Data Policy, Data Contract, Data Control, and Control Evidence; and
enterprise/domain ontology semantics, which define the business subject matter of a particular enterprise or domain, such as Party, Customer, Account, Payment, Trade, Instrument, Product, Settlement, or Risk.

GEDRM therefore supplies the semantic grammar for data architecture, while enterprise and domain ontologies supply the business vocabulary being governed.

For example:

GEDRM concept:
  Master Data
       |
       | classifies
       v
Enterprise business concept:
  Party
       |
       +-- Person
       |
       +-- Organisation

and:

Enterprise concept:
  Payment
       |
       +-- hasDebtorParty --> Party
       +-- hasCreditorParty --> Party
       +-- hasCurrency --> Currency
       +-- hasStatus --> PaymentStatus

The existence of an enterprise concept such as Payment does not make Payment a new GEDRM core concept.

6.1.4 Core Semantic Constructs

A GEDRA-aligned Semantic & Enterprise Ontology Plane SHOULD be capable of representing the following constructs.

Business Concept

A governed expression of a business idea or subject with an explicit meaning.

Examples: Party, Account, Payment, Trade, Instrument, Product, Settlement, Risk.

Entity

A business concept for which distinct instances can be identified within a governed context.

Examples: Party P12345, Account A9981, Payment PAY-2026-001.

Attribute / Property

A governed characteristic of a concept or entity.

Examples: Payment.amount, Account.currency, Party.legalName.

Attribute meaning SHOULD be separable from a particular physical column, JSON field, API property, or storage representation.

Semantic Relationship

A governed relationship between concepts.

Examples:

Party       --holds-->         Account
Payment     --debitedFrom-->   Account
Payment     --creditedTo-->    Account
Trade       --references-->    Instrument

Relationships SHOULD carry explicit direction and meaning where direction is semantically material.

Taxonomy / Controlled Vocabulary

A governed set of categories, codes, classifications, or values used to classify, constrain, interpret, or validate data.

This aligns with GEDRM Reference Data semantics where the vocabulary values themselves are data.

Examples include currency codes, payment-status codes, legal-entity types, country codes, and risk classifications.

Semantic Mapping

An explicit mapping between two semantic representations.

A mapping MAY express equivalence, broader/narrower meaning, transformation, external-standard correspondence, legacy-to-canonical mapping, or domain-to-enterprise mapping.

A semantic mapping MUST NOT imply exact equivalence unless exact equivalence has been governed as such.

6.1.5 Enterprise Ontology and Domain Ontology

GEDRA does not require one monolithic enterprise ontology.

A conforming architecture MAY use:

Enterprise Ontology
        |
        +-- shared cross-domain concepts
        |
        +-- Domain Ontology A
        |
        +-- Domain Ontology B
        |
        +-- Domain Ontology C

Domain ontologies MAY extend enterprise concepts with domain-specific meaning.

Where the same concept is used across domains, the architecture SHOULD make one of the following explicit: shared canonical meaning, specialization, contextualized domain meaning, semantic mapping, or intentional non-equivalence.

Silent semantic divergence SHOULD be avoided.

6.1.6 Identity, Role, and Classification

The plane MUST distinguish a business entity from roles or classifications applied to it.

For example:

Party
 |
 +-- may play --> Customer
 +-- may play --> Debtor
 +-- may play --> Creditor
 +-- may play --> Supplier

A role SHOULD NOT automatically be modeled as a separate underlying entity where the distinction is contextual.

Similarly:

Product PRD-1042
    = Master Data entity

Product Type = MORTGAGE
    = Reference Data classification

The semantic plane SHOULD preserve the GEDRM distinction between business identity and controlled classification.

6.1.7 Semantic Classification Model

The plane SHOULD support GEDRM's faceted classification model.

A data object or element MAY simultaneously carry classifications from different dimensions, for example:

Customer Record
  Business/Semantic: Master Data
  Legal/Sensitivity: Personal Data
  Processing State:  Mastered

or:

Calculated FX Forward Rate
  Business/Semantic: Market Data
  Provenance:        Derived Data

Architectures MUST NOT force orthogonal GEDRM classification dimensions into one mutually exclusive flat taxonomy.

6.1.8 Canonical Semantics vs Canonical Physical Model

GEDRA distinguishes canonical semantics from a mandatory canonical physical schema.

The enterprise MAY establish a canonical semantic concept without requiring every system or interface to adopt one identical physical representation.

For example:

Canonical semantic concept:
  Party

Representations:
  CRM.Customer
  Payments.Debtor
  KYC.Subject
  Warehouse.PartyDim

These representations MAY differ structurally while mapping to the governed Party concept.

Therefore:

Canonical meaning does not require universal physical-schema uniformity.

A canonical data model MAY be adopted where useful, but GEDRA does not require one enterprise-wide physical schema as a prerequisite for semantic consistency.

6.1.9 Critical Data Elements

Critical Data Element (CDE) is treated by GEDRA as an enterprise or profile-specific governance construct unless and until formalized as a GEDRM core concept.

Where an enterprise uses CDEs, the Semantic & Enterprise Ontology Plane SHOULD ensure that a CDE is associated with a governed semantic definition, business concept or attribute, accountable ownership, applicable classifications, applicable quality expectations, lineage where required, and authoritative sourcing context where required.

GEDRA MUST NOT assume that only CDEs require semantic governance.

6.1.10 External Standards and Semantic Alignment

The plane SHOULD support explicit mappings to external standards where applicable.

Examples MAY include ISO standards, regulatory vocabularies, industry message models, externally governed taxonomies, and jurisdiction-specific classifications.

An external standard SHOULD NOT automatically override enterprise meaning.

The mapping SHOULD state whether the relationship is equivalent, specializes, broader-than, narrower-than, maps-to, or transforms-to where that distinction is material.

6.1.11 Inputs

Typical inputs MAY include business definitions, regulatory definitions, external standards, domain models, conceptual/logical data models, existing schemas, event definitions, Data Contracts, Data Product definitions, business glossaries, reference-data vocabularies, data-quality findings, consumer interpretation issues, and architecture decisions.

Physical schemas MAY provide evidence of existing representations but MUST NOT automatically become the semantic authority.

6.1.12 Outputs

Typical outputs MAY include governed concept definitions, enterprise/domain ontology entries, semantic identifiers, entity and attribute definitions, semantic relationships, controlled taxonomies, classification mappings, external-standard mappings, canonical semantic models, semantic mapping rules, semantic compatibility decisions, semantic change records, and semantic metadata consumed by contracts, products, lineage, quality, and discovery capabilities.

6.1.13 Interaction with the Authority Plane

The Semantic & Enterprise Ontology Plane answers:

What does the data mean?

The Authority Plane answers:

For this meaning and scope, where is authoritative state maintained, from where should it be sourced, and who or what designates that authority?

The two concerns MUST remain distinguishable.

For example:

Semantic Plane:
  Payment.status
      means the governed lifecycle state of a Payment

Authority Plane:
  Payment Processing System
      records authoritative state for Payment.status
      during processing

  Settlement System
      records authoritative state for Settlement.status

A semantic definition does not establish source authority.

6.1.14 Interaction with Processing, Provision & Movement

Processing capabilities SHOULD preserve or explicitly transform semantic meaning.

Where processing materially changes meaning, structure, classification, or derivation state, the transformation SHOULD be traceable.

For example:

PaymentInstruction.amount
       |
       | transformation / aggregation
       v
DailyPaymentVolume.totalAmount

The output is not semantically equivalent to its input merely because it was derived from it.

6.1.15 Interaction with the Data Platform & Product Plane

Data Assets and Data Products SHOULD reference governed semantics for their exposed data.

A Data Product SHOULD NOT have to invent private meanings for concepts that already have governed enterprise/domain semantics unless it explicitly declares a specialization or contextual interpretation.

The semantic plane MAY therefore supply concept identifiers, definitions, field-to-concept mappings, controlled vocabularies, semantic versions, and compatibility mappings to Data Product descriptors, schemas, Data Contracts, catalogs, registries, and output ports.

6.1.16 Interaction with Consumption & Access

Consumers SHOULD be able to discover what data means before or alongside accessing it.

Consumer-facing metadata SHOULD enable users and systems to determine business meaning, applicable scope, classifications, relationship to other concepts, semantic version, product or dataset representation, and known mappings to external vocabularies.

Access to data and understanding of data are separate concerns.

6.1.17 Interaction with Governance & Control

Semantic governance MAY be supported by ownership and stewardship, approval workflows, semantic-change controls, classification controls, vocabulary governance, contract validation, schema-to-semantic mapping checks, and evidence of review or approval.

However, a glossary entry, ontology entry, taxonomy, metric, or validation report is not automatically a GEDRM Data Control.

A mechanism becomes a Data Control only where it satisfies the GEDRM assurance semantics for a defined governed expectation.

6.1.18 Semantic Evolution

Semantic definitions MUST be evolvable without silently changing meaning for existing consumers.

A semantic change SHOULD be assessed as one of: editorial/non-semantic, backward-compatible clarification, additive, specialization, deprecation, or materially incompatible semantic change.

Material semantic changes SHOULD be versioned and SHOULD trigger impact analysis across Authoritative Sources, transformations, Data Contracts, Data Products, Data Quality Rules, Data Controls, consumers, regulatory mappings, and AI/ML features or models where applicable.

6.1.19 Architectural Boundaries

The Semantic & Enterprise Ontology Plane does not own physical persistence, operational system state, authority designation, movement or transport, runtime transformation, product lifecycle execution, consumer entitlement, or infrastructure.

It MAY define semantic metadata used by capabilities that perform those responsibilities.

6.1.20 Anti-Patterns

The following are GEDRA semantic-plane anti-patterns:

Schema Equals Meaning — treating a database table, API schema, protobuf definition, JSON document, or file layout as the enterprise semantic model without explicit semantic governance.
Application-Owned Meaning by Default — assuming each application may independently define enterprise concepts without reconciliation.
One Word Means One Thing Everywhere — assuming identical labels imply semantic equivalence.
One Physical Canonical Model for Everything — forcing all systems into one physical schema merely to obtain semantic consistency.
Flat Classification Taxonomy — forcing Master, Reference, Derived, Personal, and Mastered into one mutually exclusive classification tree.
Technology-Derived Ontology — constructing enterprise semantics solely from application inventories, database catalogs, or platform objects.
Ungoverned Synonyms — allowing multiple names for the same concept, or the same name for different concepts, without explicit mappings or distinctions.

6.1.21 Minimum GEDRA 0.1 Conformance Expectations

An architecture claiming alignment with the Semantic & Enterprise Ontology Plane SHOULD demonstrate that:

governed business meaning is identifiable independently of physical implementation;
key enterprise/domain concepts have explicit definitions;
material semantic relationships can be represented;
semantic classifications align with GEDRM where GEDRM applies;
orthogonal GEDRM classification dimensions are not incorrectly collapsed;
mappings between materially different representations are explicit where required;
semantic ownership or stewardship can be identified under the enterprise governance model;
semantic change can be governed and impact-assessed;
the architecture distinguishes semantic authority from operational or sourcing authority;
data products and consumer interfaces can reference governed semantics;
external-standard mappings do not silently assert equivalence;
application or technology models are not treated as the sole enterprise semantic authority by default.

6.1.22 Illustrative Enterprise View

                     SEMANTIC & ENTERPRISE ONTOLOGY PLANE

 Business Concepts        Relationships          Classifications
 -----------------        -------------          ---------------
 Party                    Party holds Account    Master Data
 Account                  Payment debits Account Reference Data
 Payment                  Trade references Instr Transactional Data
 Trade                                            Market Data
 Instrument                                       Personal Data
                                                  Derived
                                                  Mastered

        |                       |                       |
        +-----------------------+-----------------------+
                                |
                                v
                    Governed Semantic Meaning
                                |
          +---------------------+--------------------+
          |                     |                    |
          v                     v                    v
   Authority Plane       Data Products        Consumers
   "where truth?"        "what promise?"       "what does it mean?"

The view is logical. The semantic repository, glossary, ontology service, metadata platform, catalog, modeling tool, or registry used to realize it is an implementation choice.

6.2 Authority Plane

6.2.1 Purpose

The Authority Plane defines how an enterprise establishes, scopes, records, designates, and communicates authority over data.

Its purpose is to make explicit:

where data originates;
who or what introduces data into a governed flow;
where authoritative operational business state is maintained;
from which source defined data SHOULD be obtained or validated;
who or what establishes or mandates that authority;
how authority varies by scope, lifecycle stage, attribute, jurisdiction, business capability, or purpose.

The Authority Plane prevents the common architectural mistake of treating data authority as an implicit property of an application, database, platform, or widely used copy.

It answers questions such as:

Where did this data first originate?
Who or what introduced it into this flow?
Which system maintains authoritative operational state for this scope?
From which source should consumers obtain or validate this data?
Who or what designated that source as authoritative?
Is the authority applicable to the whole entity, only selected attributes, or only a lifecycle stage?
Does a derived or mastered representation carry authority, and if so, by what governance decision?
Is a distributor merely authorized to distribute, or authoritative for truth?

6.2.2 Core GEDRM Roles

The Authority Plane uses the following GEDRM roles and concepts.

Data Originator

A party that originally creates data.

Primary question:

Where did the data first originate?

Origination does not imply ownership, authority, or authorization to distribute.

A Data Originator MAY also be a Data Producer.

Data Producer

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

Primary question:

Who or what introduces the data into this flow?

The Data Producer MAY be the same capability as the Data Originator or System of Record, but those roles MUST NOT be assumed equivalent.

System of Record

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

Primary question:

Where is the authoritative business state maintained?

A System of Record MUST be interpreted as a scoped state-authority role.

A system MAY be a System of Record for:

one entity but not another;
selected attributes only;
one lifecycle stage;
one jurisdiction;
one business process;
one effective time period.

Different systems MAY therefore be Systems of Record for different parts of the same end-to-end business lifecycle.

Authoritative Source

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?

An Authoritative Source MAY be:

the System of Record;
a governed projection of a System of Record;
a mastered source;
a derived source;
an assembled source integrating multiple Systems of Record.

Being an Authoritative Source does not require being the System of Record.

Source of Authority

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

Primary question:

Who or what establishes that this source or representation is authoritative?

A Source of Authority MAY include, depending on enterprise context:

Data Owner;
governance body;
policy;
law or regulation;
statutory authority;
contract;
architecture decision;
formally approved governance decision.

Source of Authority MUST NOT be treated as synonymous with System of Record or Authoritative Source.

6.2.3 Core Authority Distinctions

GEDRA 0.1 requires the following distinctions to remain explicit.

Data Originator
    = where data first originates

Data Producer
    = who/what introduces data into a flow

System of Record
    = where authoritative operational state is maintained

Authoritative Source
    = where governed consumers should obtain or validate defined data

Source of Authority
    = who/what establishes or mandates that authority

These concepts MAY be co-located in one implementation, but their meanings MUST remain distinct.

6.2.4 State Authority vs Sourcing Authority vs Designation Authority

GEDRA distinguishes three authority dimensions.

State Authority — expressed primarily through the System of Record role: where authoritative operational state is maintained.
Sourcing Authority — expressed primarily through the Authoritative Source role: from where governed consumers should obtain or validate the data.
Designation Authority — expressed through Source of Authority: who or what determines that a source, value, or representation is authoritative.

These three MAY resolve to different actors or capabilities.

6.2.5 Authority Is Always Scoped

No GEDRA role is globally authoritative by default.

Authority SHOULD be modeled against an explicit governed scope.

A scope MAY include:

business concept;
entity;
attribute;
event;
lifecycle state;
jurisdiction;
business capability;
consumer purpose;
legal basis;
time period;
product;
contract boundary.

Architectures SHOULD avoid statements such as:

"System X is the authoritative system for Customer"

unless the exact governed scope has been defined.

6.2.6 Authority May Be Distributed

GEDRA explicitly supports distributed authority.

A single business entity MAY have authoritative state distributed across multiple systems, lifecycle stages, attributes, jurisdictions, legal regimes, or business capabilities.

Distributed authority is not an architectural defect if the boundaries are intentional, explicit, governed, and discoverable.

6.2.7 Derived and Mastered Authority

Processing, derivation, mastering, reconciliation, or aggregation do not automatically establish authority.

A Derived Data object MAY become an Authoritative Source only where it is explicitly designated as such.

Similarly:

Mastered != Authoritative Source
Golden Record != System of Record
Golden Record != Authoritative Source

A Golden Record MAY be exposed through an Authoritative Source where governance explicitly establishes that status for a defined scope.

6.2.8 Authoritative vs Authorized

GEDRA requires a strict distinction between authoritative and authorized.

Authoritative means recognized as having authority concerning the validity, trust, or preferred sourcing of defined data.

Authorized means permitted or approved to perform a role.

Therefore:

Authorized Data Distributor != Authoritative Source

A capability may be authorized to distribute data without being authoritative for its truth.

6.2.9 HDIP Specialization

GEDRA remains generic.

HDIP-specific concepts are represented as specializations or mappings.

HDIP Authorized Data Source (ADS) is a governed specialization of Authoritative Source.
If adopted, HDIP Authorized Data Originator (ADO) is a governed specialization of Data Originator.
HDIP Authorized Data Distributor (ADD) belongs primarily in the Processing, Provision & Movement Plane as a governed specialization of Data Distributor.

The generic GEDRA Authority Plane SHOULD therefore use Authoritative Source, not ADS.

ADD MUST NOT be interpreted as authoritative merely because it is authorized to distribute.

6.2.10 Authority Designation Pattern

GEDRA defines the following reusable pattern:

Source of Authority
        |
        | establishes-authority-for
        | designates-authoritative-source
        v
Authoritative Source
        |
        | is-authoritative-source-for
        v
Governed Data Scope

Where operational state is relevant:

System of Record
        |
        | records-authoritative-state-for
        v
Governed State Scope

The Source of Authority MAY designate the System of Record itself as the Authoritative Source, but this is not mandatory.

6.2.11 Authoritative Sourcing Pattern

A typical authoritative sourcing pattern is:

System(s) of Record
        |
        | governed extraction / projection / assembly
        v
Authoritative Source
        |
        | approved sourcing relationship
        v
Data Product / Consumer / Processing Capability

The intermediate Authoritative Source MAY be physically persisted, virtual, federated, or assembled.

The architecture SHOULD state:

authoritative scope;
source-of-authority basis;
upstream source lineage;
applicable effective period;
consumer purpose where relevant;
whether the source is direct or derived.

6.2.12 Interaction with the Semantic Plane

The Semantic & Enterprise Ontology Plane defines:

What does the data mean?

The Authority Plane defines:

Where is authoritative state maintained, where should the data be sourced, and who establishes that authority?

A semantic concept MUST NOT become authoritative merely because it is canonical.

Likewise, a physically authoritative source MUST NOT be assumed to define enterprise semantic meaning.

6.2.13 Interaction with Processing, Provision & Movement

A Data Transformer MAY consume data from an Authoritative Source but does not inherit authority merely by transforming it.

A Data Distributor MAY distribute authoritative data but is not automatically authoritative.

A Data Publisher MAY publish authoritative data without being the source that established or maintained that authority.

A Data Broker MAY mediate access to authoritative data while having no authority over the data itself.

6.2.14 Interaction with the Data Platform & Product Plane

A Data Product SHOULD be able to identify the authority context of material data it exposes.

Depending on the product and consumer obligation, this MAY include:

source-of-authority basis;
System-of-Record lineage;
Authoritative Source;
authoritative scope;
effective period;
derivation path;
known authority limitations.

A Data Product MAY itself be an Authoritative Source if explicitly governed as such.

Productization alone MUST NOT grant authoritative status.

6.2.15 Interaction with Consumption & Access

Consumers SHOULD be able to determine whether data is:

from an Authoritative Source;
a non-authoritative copy;
derived;
cached;
replicated;
provisional;
stale;
historical;
authoritative only for a limited scope.

A widely consumed copy MUST NOT silently become authoritative by popularity.

6.2.16 Interaction with Governance & Control

Authority decisions SHOULD be governable and evidential.

The architecture MAY support:

authority designation approvals;
source registration;
scope registration;
effective dates;
review cycles;
exception management;
ownership;
policy references;
evidence of approval;
controls ensuring consumers source data from approved sources.

A Data Control MAY verify, for example, that critical regulatory reporting data is sourced only from the designated Authoritative Source.

The control is distinct from the authority designation itself.

6.2.17 Change and Invalidation

Authority changes can have significant downstream impact.

When an Authoritative Source or System-of-Record scope changes, the architecture SHOULD support impact analysis across:

Data Products;
Data Contracts;
transformations;
distribution paths;
lineage;
controls;
regulatory reports;
analytics;
AI/ML features;
consumer applications;
caches and copies.

Changes SHOULD preserve an auditable history of previous authority, new authority, scope, effective date, approving Source of Authority, affected consumers, and migration or transition state.

6.2.18 Architectural Boundaries

The Authority Plane does not own:

semantic definitions;
physical transformation logic;
distribution mechanics;
consumer entitlement;
storage technology;
application topology;
product lifecycle;
data-quality calculation logic.

It MAY provide authority metadata and decisions consumed by capabilities performing those responsibilities.

6.2.19 Anti-Patterns

The following are Authority Plane anti-patterns:

Application Equals Authority — assuming an application is authoritative simply because it is operational.
Popular Copy Equals Authoritative Source — treating the most widely used warehouse, lake, cache, or replica as authoritative without explicit designation.
SoR Equals Authoritative Source Everywhere — assuming the SoR must always be the preferred enterprise consumption source.
Mastered Means Authoritative — assuming mastered data is automatically authoritative.
Golden Record Means Source of Truth — using Golden Record as a synonym for SoR or Authoritative Source.
Authorized Equals Authoritative — treating a capability approved to distribute data as authoritative for its truth.
Global Authority Without Scope — declaring an entire system authoritative without identifying the governed scope.
Authority by Technology — treating a database type, cloud platform, MDM tool, warehouse, lakehouse, ledger, or event platform as inherently authoritative.
Silent Authority Migration — changing authority without explicit effective dates, impact analysis, and governance evidence.

6.2.20 Minimum GEDRA 0.1 Conformance Expectations

An architecture claiming alignment with the Authority Plane SHOULD demonstrate that:

material authority is explicitly scoped;
Data Originator and Data Producer are not silently assumed equivalent;
System of Record and Authoritative Source are distinguished;
Source of Authority can be identified for material authority designations;
authoritative and authorized are distinguished;
derived, mastered, replicated, or cached data does not gain authority implicitly;
authority may be distributed across lifecycle stages or attributes;
downstream consumers can identify relevant authoritative sourcing context;
authority changes can be impact-assessed;
HDIP ADS/ADO terminology is treated as specialization rather than generic GEDRA terminology;
ADD is not treated as authoritative merely because it is authorized to distribute;
architecture documentation does not rely on vague phrases such as "single source of truth" without defining semantic and authority scope.

6.2.21 Illustrative Authority View

                           AUTHORITY PLANE

                     Source of Authority
                  governance / law / policy
                           / owner
                              |
                 designates-authoritative-source
                              |
                              v
                    Authoritative Source
                   "where should I source?"
                              |
                 +------------+------------+
                 |                         |
                 v                         v
        System of Record A        System of Record B
       "authoritative state"     "authoritative state"
        initiation stage          settlement stage

                 ^                         ^
                 |                         |
            Data Producer             Data Producer
                 ^                         ^
                 |                         |
            Data Originator          Data Originator

The roles shown are logical. A single implementation MAY perform several of them, and one business lifecycle MAY distribute them across multiple capabilities.

6.3 Processing, Provision & Movement Plane

6.3.1 Purpose

The Processing, Provision & Movement Plane defines how data is transformed, derived, transported, exposed, published, distributed, and mediated between producers, authoritative sources, products, platforms, and consumers.

Its purpose is to make explicit the distinct operational roles involved in moving data through an enterprise without collapsing them into one generic “integration” or “pipeline” concern.

The plane answers questions such as:

Who transforms the data?
Who transports or relays it?
Who makes it available?
Who intentionally publishes it?
Who distributes it to permitted recipients?
Who mediates discovery, selection, access, entitlement, or exchange?
Which responsibilities are operational, which are governance-related, and which imply no authority over truth?
Where are transformations and derivations introduced?
Where do semantic or contractual obligations need to be preserved across movement?

The plane SHOULD support both point-to-point and graph-shaped enterprise data flows.

6.3.2 Core GEDRM Roles

The Processing, Provision & Movement Plane uses the following GEDRM operational roles.

Data Transformer

A party or capability that changes data through processing.

Typical transformations MAY include:

validation;
mapping;
normalization;
enrichment;
aggregation;
correlation;
reconciliation;
derivation;
format conversion;
filtering;
masking;
tokenization;
feature engineering.

Primary question:

Who or what changes the data?

A Data Transformer MUST NOT be called a Data Processor merely because it processes data, because Data Processor has a distinct legal/privacy meaning in GEDRM.

A Data Transformer does not become authoritative merely because it transforms data.

Data Transport / Relay

A party or capability that moves, forwards, relays, or conveys data between locations, services, systems, or participants.

Primary question:

Who or what carries the data from one point to another?

Examples MAY include:

message transport;
event relay;
file transfer;
replication transport;
API gateway transport;
networked delivery;
streaming relay.

Transport SHOULD be distinguished from transformation and distribution responsibility.

Data Provider

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

Primary question:

Who makes the data available?

A Data Provider MAY expose data directly or through another Publisher, Distributor, Broker, or platform capability.

Availability alone does not imply publication intent, authority, ownership, or product status.

Data Publisher

A party or capability that intentionally exposes or releases data under a defined publication context.

Primary question:

Who deliberately publishes or releases the data?

Publication MAY include:

interface definition;
output-port exposure;
release/version context;
Data Contract;
policy conditions;
product promise;
publication lifecycle;
deprecation rules.

Publication is stronger than mere availability.

A Data Publisher MAY also be a Data Provider or Data Distributor, but these roles MUST NOT be assumed equivalent.

Data Distributor

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

Primary question:

Who delivers the data?

Distribution MAY be:

push-based;
pull-based;
scheduled;
event-driven;
streaming;
query-mediated;
file-based;
API-based.

A Data Distributor does not become authoritative for the data merely by distributing it.

Data Broker

An intermediary that mediates the relationship between providers/publishers and consumers.

Primary question:

Who mediates discovery, selection, access, exchange, policy, entitlement, routing, or provider-consumer interaction?

A Data Broker MAY facilitate:

discovery;
negotiation;
entitlement;
policy evaluation;
routing;
provider selection;
marketplace interaction;
subscription;
exchange coordination.

A technical message broker such as Kafka MUST NOT automatically be modeled as a GEDRM Data Broker.

Technology naming does not determine semantic role.

6.3.3 Core Role Distinctions

GEDRA 0.1 requires the following distinctions to remain explicit:

Data Transformer
    = changes data

Data Transport / Relay
    = carries data

Data Provider
    = makes data available

Data Publisher
    = intentionally publishes/releases data

Data Distributor
    = delivers data to permitted recipients

Data Broker
    = mediates the provider-consumer relationship

One implementation MAY perform several of these roles.

For example:

Data Product Output Port
    may act as:
      Data Provider
      Data Publisher

Distribution Service
    may act as:
      Data Distributor

Marketplace
    may act as:
      Data Broker

The architecture SHOULD model the semantic responsibility, not infer role from product or technology name.

6.3.4 Processing vs Provision vs Movement

GEDRA separates three broad concerns.

Processing

Processing changes data.

Examples:

validate
map
normalize
enrich
aggregate
correlate
derive
reconcile

Primary role:

Data Transformer

Provision

Provision makes data available or intentionally publishes it.

Primary roles:

Data Provider
Data Publisher

Movement

Movement carries or delivers data.

Primary roles:

Data Transport / Relay
Data Distributor

Mediation across provider-consumer relationships is represented by:

Data Broker

These concerns MAY occur together operationally but SHOULD remain distinguishable architecturally.

6.3.5 Transformation and Derivation

The plane SHOULD distinguish ordinary structural transformation from semantic derivation where the distinction matters.

Examples:

Schema mapping:
  source.customer_id
      -> target.partyId

may preserve meaning.

Whereas:

Payment events
      |
      | aggregate
      v
Daily payment volume

creates Derived Data.

GEDRA SHOULD preserve lineage between inputs, transformation/derivation activity, and outputs.

A useful pattern is:

Input Data
    |
    | isInputTo
    v
Derivation Activity
    |
    | produces
    v
Derived Data

Processing MAY change representation without changing meaning, or MAY change meaning materially.

The architecture SHOULD make that distinction explicit where required.

6.3.6 Processing Does Not Confer Authority

A Data Transformer does not inherit the authority of its inputs.

For example:

Authoritative Source
      |
      v
Data Transformer
      |
      v
Derived Dataset

The Derived Dataset is not automatically authoritative.

It MAY become an Authoritative Source only through explicit authority designation under the Authority Plane.

Likewise, a Data Distributor does not become authoritative merely because it distributes authoritative data.

6.3.7 Provision vs Publication

GEDRA distinguishes availability from governed publication.

A Data Provider may make data technically accessible.

A Data Publisher intentionally releases data under an explicit publication context.

For example:

Database query endpoint
    = may be a Data Provider

Versioned Data Product output port
    = Data Publisher
      and may also be Data Provider

Publication SHOULD be used where release semantics matter, including:

compatibility expectations;
versioning;
lifecycle;
discoverability;
policy;
contract;
product promise;
consumer commitment.

6.3.8 Distribution vs Transport

Data Transport / Relay and Data Distributor SHOULD remain distinct.

A transport capability primarily carries data.

A distributor is responsible for delivering data to permitted recipients.

For example:

Network / Messaging Runtime
    = Transport / Relay

Governed Distribution Service
    = Data Distributor

A single technical component MAY realize both, but the responsibilities remain distinct.

6.3.9 Broker Semantics

A Data Broker mediates the provider-consumer relationship.

A broker MAY operate without originating, owning, persisting, or physically delivering the data.

Examples MAY include:

data marketplace;
federated discovery service;
entitlement mediation service;
exchange coordination service;
provider-selection service.

A Kafka broker, message queue, API gateway, or routing platform SHOULD NOT automatically be called a Data Broker unless it performs the semantic mediation role defined by GEDRM.

6.3.10 Governed Distribution Pattern

GEDRA defines the following reusable pattern:

Authoritative Source / Data Product
            |
            v
       Data Publisher
            |
            v
       Data Provider
            |
            v
      Data Distributor
            |
            v
   Permitted Consumer

A Broker MAY mediate the relationship:

              Data Broker
             /          \
            /            \
     Publisher         Consumer

The exact physical implementation MAY collapse several roles into one capability.

6.3.11 Direct, Mediated, and Productized Provision

GEDRA supports multiple provision patterns.

Direct Provision

Authoritative Source
      |
      v
Data Provider
      |
      v
Consumer

Published Provision

Data Publisher
      |
      v
Published Interface
      |
      v
Consumer

Mediated Provision

Provider / Publisher
      |
      v
Data Broker
      |
      v
Consumer

Productized Provision

Data Product
      |
      v
Output Port / Publisher
      |
      v
Distributor / Broker
      |
      v
Consumer

GEDRA does not require every data flow to become a Data Product.

6.3.12 Data Contract Interaction

Where data is intentionally published or productized, Data Contracts SHOULD define the relevant interaction commitments.

A Data Contract MAY define:

schema;
semantics;
mandatory attributes;
version;
compatibility;
freshness;
completeness;
availability;
usage constraints;
deprecation expectations.

The Processing, Provision & Movement Plane SHOULD ensure that transformations and movement do not silently violate contract commitments.

A Data Contract is not the transport itself.

6.3.13 Policy Interaction

Applicable Data Policies MAY constrain:

what data may move;
where it may move;
who may receive it;
whether it may cross jurisdictions;
whether it may be transformed;
whether fields must be masked;
whether data may be persisted;
how long it may be retained;
whether redistribution is permitted.

Policy enforcement MAY be implemented within processing, publication, distribution, or broker capabilities.

The policy remains a governed normative artifact even where executable Policy as Code is bound into runtime components.

6.3.14 Privacy Interaction

Where Personal Data is processed, moved, published, or distributed, GEDRA SHOULD preserve the distinction between:

Data Transformer

and:

Data Processor

The former is an operational data-flow role.

The latter is a legal/privacy role defined relative to a Processing Activity and Data Controller.

One capability MAY simultaneously act as both, but the architecture MUST NOT infer legal role from technical processing behavior.

6.3.15 Interaction with Semantic & Enterprise Ontology

Transformations SHOULD preserve or explicitly map semantic meaning.

Where fields or representations differ, semantic mapping SHOULD be traceable.

For example:

Source:
  debtorCustomerNumber

Semantic concept:
  PartyIdentifier

Published target:
  debtorPartyId

The semantic plane defines the meaning; the processing plane implements the mapping.

6.3.16 Interaction with Authority Plane

Processing and movement SHOULD respect authority context.

The plane SHOULD be able to identify:

whether input is authoritative;
for what scope;
whether output remains a copy, transformation, derivation, or authoritative representation;
whether a published endpoint is exposing authoritative or non-authoritative data.

Transformation or distribution MUST NOT silently reclassify authority.

6.3.17 Interaction with Data Platform & Product Plane

Platform capabilities MAY realize processing, publication, distribution, or broker roles.

Examples MAY include:

ingestion;
orchestration;
transformation engines;
streaming services;
API platforms;
output-port runtimes;
product gateways;
marketplace services.

The fact that a platform implements the capability does not make the platform itself the semantic role.

A Data Product MAY use this plane to expose and deliver its product promise.

6.3.18 Interaction with Consumption & Access

Consumers may interact with this plane through:

APIs;
events;
streams;
datasets;
files;
queries;
output ports;
subscriptions;
marketplace-mediated access.

The mode of access SHOULD be distinguished from the semantic role of the provider or distributor.

6.3.19 Interaction with Governance & Control

Governance and controls MAY apply to:

source selection;
transformation logic;
schema compatibility;
quality;
masking;
residency;
distribution entitlement;
policy enforcement;
publication approval;
delivery monitoring;
contract conformance;
redistribution rules.

Controls SHOULD be linked to evidence where assurance is required.

For example:

Policy:
  Personal Data must not leave approved jurisdiction.

Control:
  Validate destination region before distribution.

Evidence:
  destinationRegion=GB
  outcome=PASS

6.3.20 Copies, Caches, and Replicas

GEDRA distinguishes movement from authority.

A copy, cache, replica, projection, or materialized view MAY be created for performance, resilience, locality, or consumer need.

Such copies MUST NOT automatically become Authoritative Sources.

Architectures SHOULD state:

why the copy exists;
source lineage;
freshness expectation;
retention;
synchronization model;
authority status;
consumer restrictions.

Intentional persistence SHOULD be governed.

6.3.21 Synchronous and Asynchronous Movement

GEDRA is agnostic to communication mode.

Movement MAY be:

synchronous
asynchronous
batch
streaming
event-driven
request/response
scheduled
continuous

The architecture SHOULD select the mode based on business and data obligations rather than technology fashion.

6.3.22 Push, Pull, and Query Patterns

GEDRA supports:

Push

Publisher / Distributor
      |
      v
Consumer

Pull

Consumer
      |
      v
Provider

Query-Mediated

Consumer
      |
      v
Query Interface / Provider
      |
      v
Data Source

Subscription

Consumer subscribes
      |
      v
Publisher / Broker
      |
      v
Recurring delivery

No one pattern is inherently more productized or governed than another.

6.3.23 Data Movement Across Boundaries

Movement across organizational, jurisdictional, cloud, network, or trust boundaries SHOULD make applicable governance visible.

Architectural concerns MAY include:

residency;
privacy;
security;
encryption;
contractual restrictions;
regulatory obligations;
cross-border controls;
lineage;
retention;
redistribution rights.

Boundary crossing is an architectural concern even when transport technology makes it operationally trivial.

6.3.24 Failure, Replay, and Delivery Semantics

Where business obligations require it, movement architecture SHOULD define:

delivery guarantee;
ordering;
idempotency;
retry;
replay;
duplicate handling;
dead-letter handling;
recovery;
late-arriving data;
partial failure behavior.

GEDRA core does not prescribe exact delivery semantics.

Profiles and concrete architectures SHOULD select them based on consumer and product obligations.

6.3.25 Observability of Movement and Processing

The architecture SHOULD enable observation of material processing and movement.

Signals MAY include:

volume;
latency;
freshness;
failure rate;
retries;
schema rejection;
distribution failure;
policy denial;
contract breach;
lineage completeness.

Observability signals are not automatically Data Controls or Control Evidence.

They MAY support controls where explicitly governed for assurance.

6.3.26 Change and Compatibility

Changes to processing, provision, or movement SHOULD be impact-assessed where they may affect:

semantics;
schema;
authority;
Data Contracts;
product promise;
consumers;
quality;
latency;
lineage;
controls;
regulatory use.

Published interfaces SHOULD adopt explicit versioning and compatibility policies where consumers depend on stable behavior.

6.3.27 Architectural Boundaries

The Processing, Provision & Movement Plane does not own:

enterprise semantic definitions;
authority designation;
product ownership;
consumer business purpose;
policy authorship;
infrastructure itself.

It MAY implement runtime behavior governed by those concerns.

6.3.28 Anti-Patterns

The following are Processing, Provision & Movement anti-patterns.

Processor Terminology Collision

Using Data Processor to mean technical transformer without regard to privacy-law semantics.

Pipeline Equals Architecture

Describing enterprise data architecture only as ETL/ELT pipelines or integration flows.

Transport Equals Distribution

Assuming a messaging or network layer is the same as governed distribution responsibility.

Technical Broker Equals Data Broker

Calling a message broker a GEDRM Data Broker merely because the product uses the word “broker”.

Exposure Equals Publication

Treating technically accessible data as intentionally published without version, contract, policy, or lifecycle context.

Distribution Equals Authority

Assuming a distributor becomes authoritative because consumers obtain data from it.

Transformation Equals Cleansing Equals Truth

Assuming transformed, enriched, reconciled, or mastered data is automatically more authoritative.

Copy Without Purpose

Creating unmanaged copies, replicas, or caches without explicit purpose, lineage, lifecycle, or authority status.

Integration-Owned Semantics

Allowing transformation teams or integration platforms to silently redefine business meaning.

6.3.29 Minimum GEDRA 0.1 Conformance Expectations

An architecture claiming alignment with this plane SHOULD demonstrate that:

transformation, transport, provision, publication, distribution, and brokerage can be distinguished;
Data Transformer is used instead of technical misuse of Data Processor;
Data Provider and Data Publisher are not silently treated as equivalent;
Data Transport / Relay and Data Distributor are distinguishable;
a technical message broker is not automatically modeled as a Data Broker;
transformations preserve or explicitly map semantic meaning;
derivation is traceable where material;
processing or distribution does not confer authority implicitly;
publication and distribution can reference relevant Data Contracts and policy obligations;
copies, caches, and replicas retain explicit lineage and authority status;
movement across trust or jurisdictional boundaries can carry applicable governance obligations;
consumer-facing changes can be impact-assessed and versioned where required.

6.3.30 Illustrative Processing, Provision & Movement View

                    PROCESSING, PROVISION & MOVEMENT PLANE

Authoritative Source / Producer
              |
              v
       Data Transformer
  validate / map / enrich / derive
              |
              v
        Data Publisher
   intentional governed release
              |
              v
         Data Provider
      makes data available
              |
              v
       Data Distributor
      governed delivery role
              |
              v
           Consumer

Optional mediation:

        Publisher / Provider
                |
                v
            Data Broker
       discovery / entitlement
        routing / mediation
                |
                v
             Consumer

Transport / Relay capabilities may carry data between any of these roles without
becoming the semantic owner, authority, publisher, distributor, or broker by default.

The view is logical rather than a mandatory physical pipeline. One capability MAY perform multiple roles, and real enterprise flows MAY branch, converge, loop, or bypass particular roles where governance and consumer obligations permit.

6.4 Data Platform & Product Plane

6.4.1 Purpose

The Data Platform & Product Plane defines the architectural responsibilities required to manage, persist, govern, discover, operationalize, and intentionally productize data.

Its purpose is to make explicit the distinction between:

platform capabilities that enable data management;
governed Data Assets;
intentional Data Products;
product lifecycle and product promise;
discoverability, metadata, lineage, quality, and observability capabilities;
implementation services that realize these responsibilities.

The plane answers questions such as:

Where is governed data managed or persisted?
Which capabilities support metadata, lineage, quality, discovery, and lifecycle?
What makes a Data Asset valuable and governable?
When does a Data Asset become a Data Product?
What product obligations are accepted?
Which outputs form the consumable product surface?
How are product versions, contracts, policies, and lifecycle governed?
Which platform capabilities support product creation without themselves becoming the product?

6.4.2 Core GEDRM Concepts

The Data Platform & Product Plane uses the following GEDRM concepts directly.

Data Object

A generic data-bearing object or representation.

A Data Object MAY or MAY NOT be a governed Data Asset.

Data Asset

A governed data resource considered valuable or potentially valuable to the enterprise.

A Data Asset MAY include:

dataset;
event collection;
governed view;
reference dataset;
mastered representation;
analytical dataset;
reusable data service output;
other governed data resource.

Not every Data Object is necessarily a Data Asset.

Data Product

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

The governing relationship is:

Data Product
    IS-A
Data Asset

but:

Data Asset
    DOES NOT IMPLY
Data Product

Productization is intentional.

6.4.3 Platform Capability vs Data Product

GEDRA requires a strict distinction between platform capability and Data Product.

A platform capability may include:

storage;
metadata;
lineage;
quality;
discovery;
ingestion;
processing;
security;
access;
policy evaluation;
orchestration;
observability;
product lifecycle tooling;
registry;
marketplace integration.

A platform capability MAY enable or host a Data Product.

It is not automatically itself a Data Product.

For example:

Lakehouse Platform
    = platform capability

Payment Lifecycle Dataset
    = Data Asset

Payment Lifecycle Data Product
    = intentionally productized Data Asset

Likewise:

Catalog
    !=
Data Product

Registry
    !=
Data Product

API Gateway
    !=
Data Product

unless intentionally modeled as a product under a broader product specification outside GEDRM.

6.4.4 Governed Persistence

The plane SHOULD support governed persistence where persistence is required.

Persistence MAY include:

operational stores;
analytical stores;
object storage;
relational stores;
document stores;
graph stores;
event retention;
feature stores;
caches;
materialized views;
managed datasets.

Persistence SHOULD be intentional.

The architecture SHOULD make clear:

why data is persisted;
authoritative status;
lifecycle;
retention;
residency;
ownership;
lineage;
synchronization;
consumer purpose;
whether the persistence is canonical, derived, cached, or replicated.

Storage technology does not determine data role.

6.4.5 Data Asset Management

A GEDRA-aligned architecture SHOULD support the management of Data Assets across their lifecycle.

Asset management MAY include:

registration;
identification;
ownership;
classification;
metadata;
lineage;
quality;
retention;
access;
discoverability;
change history;
deprecation;
archival;
deletion.

A Data Asset MAY be valuable and governed without being productized.

6.4.6 Productization Decision

GEDRA adopts the principle:

The question is not whether a Data Asset can be modeled as a Data Product, but whether it should be productized.

The accountable owner SHOULD consider whether productization is justified by:

repeatable consumer demand;
material reuse;
external or cross-domain consumption;
regulatory or evidential importance;
need for explicit service commitments;
lifecycle independence;
discoverability needs;
compatibility/versioning expectations;
accountability requirements;
economic significance;
need for managed consumer experience.

Productization SHOULD NOT be automatic merely because data is:

stored;
shared;
high quality;
in a catalog;
exposed through an API;
used by several teams.

6.4.7 Product Promise

A Data Product SHOULD carry an explicit Product Promise.

The Product Promise expresses the governed consumer-facing commitment associated with the product.

It MAY include commitments around:

semantic meaning;
quality;
freshness;
availability;
timeliness;
completeness;
compatibility;
support;
lifecycle;
deprecation;
discoverability;
access;
provenance;
lineage;
policy obligations.

The Product Promise SHOULD be traceable to operational mechanisms that allow those commitments to be governed, observed, and where appropriate controlled.

6.4.8 Product Identity

A Data Product SHOULD have stable identity independent of any one physical deployment.

Product identity SHOULD support:

product name;
unique identifier;
owner;
version;
status;
lifecycle;
scope;
semantic meaning;
product promise;
output interfaces;
policy and contract references.

A deployment, dataset copy, API endpoint, or table MUST NOT be treated as the complete identity of the Data Product.

6.4.9 Versioning

Data Products SHOULD be versioned where changes may affect consumers.

Versioning MAY apply to:

semantic meaning;
schema;
contract;
product promise;
policy bundle;
output interface;
compatibility behavior;
lifecycle.

The architecture SHOULD make clear whether a change is:

backward-compatible;
additive;
deprecating;
materially incompatible.

Versioning SHOULD support reproducibility where regulatory, evidential, or analytical requirements demand it.

6.4.10 Output Ports / Product Interfaces

A Data Product MAY expose one or more governed output interfaces.

These MAY include:

dataset;
API;
event stream;
query endpoint;
file;
subscription;
semantic service;
feature interface.

An output port SHOULD NOT be confused with the Data Product itself.

The relationship is:

Data Product
      |
      | exposes
      v
Output Port / Product Interface

The output port MAY play Data Publisher and/or Data Provider roles in the Processing, Provision & Movement Plane.

6.4.11 Discoverability

A Data Product SHOULD be discoverable to intended consumers.

Discoverability MAY include:

catalog registration;
registry entry;
marketplace listing;
metadata search;
semantic search;
ownership details;
documentation;
usage guidance;
lineage;
quality indicators;
access instructions.

A marketplace is optional.

A catalog or registry MAY be sufficient for discovery where commercialization, exchange, or broader product marketplace behavior is not required.

6.4.12 Catalog, Registry, and Marketplace Distinction

GEDRA distinguishes these capabilities.

Catalog

Primarily supports discovery and metadata browsing.

Registry

Primarily supports governed registration, identity, version, status, canonical descriptors, or lifecycle records.

Marketplace

Primarily supports consumer-oriented discovery, selection, exchange, entitlement, commercial or non-commercial acquisition, and possibly broker behavior.

A Data Product does not require a marketplace to be a product.

6.4.13 Metadata

Metadata capabilities SHOULD support the information required to understand, govern, discover, and operate Data Assets and Data Products.

Metadata MAY include:

semantic metadata;
technical metadata;
operational metadata;
governance metadata;
lineage metadata;
quality metadata;
ownership;
classification;
product metadata;
policy references;
contract references;
version information;
lifecycle status.

Metadata SHOULD be treated as an enabling governance capability, not merely a documentation afterthought.

6.4.14 Lineage

Lineage SHOULD enable material relationships between:

origin;
authoritative source;
transformation;
derivation;
Data Asset;
Data Product;
output interface;
consumer.

Lineage MAY include:

business lineage
semantic lineage
technical lineage
processing lineage
product lineage

Lineage SHOULD support impact analysis and evidential reproducibility where required.

Lineage itself is not automatically a Data Control.

6.4.15 Data Quality

The plane SHOULD support Data Quality capabilities aligned to GEDRM's distinction between:

Data Quality Rule
    !=
Data Control

Data Quality Rules define how quality conditions are evaluated.

Data Controls operationally assure, prevent, detect, correct, verify, or evidence governed expectations.

A platform MAY implement both but SHOULD preserve their semantic distinction.

6.4.16 Data Contracts

Data Products SHOULD use Data Contracts where explicit provider/product-consumer commitments are required.

A Data Contract MAY include:

schema;
semantic definitions;
mandatory attributes;
compatibility;
version;
freshness;
completeness;
quality expectations;
availability;
usage constraints;
deprecation expectations.

The Data Contract is a governed interaction artifact.

It is not the same thing as the Data Product, schema, or API specification.

6.4.17 Policy as Code and Product-Local Governance

Where productization uses executable governance, GEDRA supports the pattern in which applicable policies are resolved and their executable representation is bundled or bound with a product version.

A product bundle MAY therefore include:

Product Descriptor
Schema
Semantic References
Data Contract
Policy as Code
Data Quality Rules
Data Controls
Control Provenance
Lineage References
Observability Definitions

The external policy remains authoritative as policy.

The bundled Policy as Code is the executable representation of resolved applicable policy.

GEDRA MUST NOT collapse all executable governance into Policy as Code.

6.4.18 Product Lifecycle

A GEDRA-aligned Data Product SHOULD have an explicit lifecycle.

A profile MAY define states such as:

Draft
Ready
Published
Active
Deprecated
Retired

GEDRA core does not mandate these exact states.

The lifecycle SHOULD support:

creation;
review;
approval;
publication;
versioning;
deprecation;
retirement;
archival where required.

6.4.19 Product Ownership

A Data Product MUST have accountable ownership under GEDRM minimum semantics.

The accountable owner is responsible for the product as a governed consumer-facing capability.

A product owner SHOULD be accountable for matters such as:

product promise;
lifecycle;
consumer obligations;
quality expectations;
versioning;
deprecation;
discovery;
support model;
governance alignment.

The product owner need not personally perform all operational tasks.

6.4.20 Data Asset Owner vs Data Product Owner

GEDRA distinguishes asset ownership from product ownership.

A Data Owner may govern the underlying Data Asset.

A Data Product Owner is accountable for the consumer-facing Data Product.

The same person or role MAY perform both responsibilities.

They MUST NOT be assumed equivalent in all operating models.

6.4.21 Consumer-Centric Productization

The decision to productize SHOULD be informed by consumer class.

Consumers likely to benefit from Data Product treatment may include:

regulatory consumers;
cross-domain enterprise consumers;
external clients;
repeated analytical consumers;
AI/ML consumers requiring stable feature semantics;
downstream Data Products;
consumers requiring explicit SLAs/SLOs, lineage, support, or compatibility.

Local or tightly coupled consumers MAY be adequately served by a governed Data Asset where product obligations add little value.

6.4.22 Product vs Business Product

GEDRA preserves the distinction between:

Business Product

and:

Data Product

A Business Product is an offering consumed to achieve a business or experiential outcome.

A Data Product is a governed data capability consumed for trusted data use.

Examples:

Business Product:
  SEPA Instant Payment

Data Product:
  Payment Lifecycle Data Product

Business Product activity MAY generate data that becomes a Data Asset or Data Product.

HDIP and GEDRA data productization do not replace business-product management.

6.4.23 Product Composition

A Data Product MAY be composed from multiple governed assets and services.

For example:

Data Product
  |
  +-- governed dataset
  +-- semantic model
  +-- output ports
  +-- Data Contract
  +-- policy bundle
  +-- DQ Rules
  +-- Data Controls
  +-- lineage
  +-- observability
  +-- documentation

The product is therefore more than a data file or table.

6.4.24 Product Dependency

A Data Product MAY depend on:

Authoritative Sources;
other Data Products;
Reference Data;
platform capabilities;
policies;
contracts;
schemas;
transformation logic.

Dependencies SHOULD be discoverable and impact-assessable where material.

A downstream Data Product SHOULD NOT hide material upstream dependency risks.

6.4.25 Non-Owning Copies

GEDRA supports the principle of avoiding unnecessary non-owning copies.

Copies MAY be justified for:

latency;
resilience;
locality;
consumer isolation;
regulatory need;
analytical workload;
historical retention.

Where copies exist, the architecture SHOULD make clear:

ownership;
authority;
source;
synchronization;
retention;
consumer purpose;
contract;
lifecycle.

A copy does not become a product merely by being persistent.

6.4.26 Economic Accountability

The plane SHOULD support economic accountability where relevant.

This MAY include:

infrastructure cost;
storage cost;
processing cost;
egress cost;
support cost;
consumer usage;
product adoption;
value realized;
heavy-consumer cost models.

Economic signals MAY inform product lifecycle and design decisions.

They do not define Data Product status by themselves.

6.4.27 Product Observability

A Data Product SHOULD support sufficient observability to assess whether it is meeting its Product Promise.

Signals MAY include:

availability;
freshness;
latency;
completeness;
quality;
schema compatibility;
consumer usage;
failure rate;
delivery success;
cost.

Observability signals are not automatically Data Controls.

They MAY feed controls where explicitly governed.

6.4.28 Interaction with the Semantic Plane

Data Assets and Data Products SHOULD reference governed semantic definitions.

The product plane SHOULD consume:

concept identifiers;
semantic definitions;
classifications;
mappings;
controlled vocabularies.

A Data Product SHOULD NOT silently redefine shared enterprise meaning.

6.4.29 Interaction with the Authority Plane

A Data Product SHOULD expose material authority context where relevant.

It MAY:

source from an Authoritative Source;
combine multiple Systems of Record;
expose derived data;
itself become an Authoritative Source if formally designated.

Productization alone does not confer authority.

6.4.30 Interaction with Processing, Provision & Movement

The plane uses processing and movement capabilities to build and expose products.

Output ports MAY play:

Data Publisher
Data Provider

Distribution services MAY play:

Data Distributor

Marketplace or mediation capabilities MAY play:

Data Broker

These operational roles remain distinct from product ownership and product identity.

6.4.31 Interaction with Consumption & Access

The product plane SHOULD provide sufficient metadata and interfaces for consumers to:

discover;
understand;
assess suitability;
request access;
consume;
monitor;
provide feedback.

Consumer experience SHOULD influence product design but SHOULD NOT erase governance obligations.

6.4.32 Interaction with Governance & Control

The product plane SHOULD integrate with governance for:

ownership;
classification;
policy;
access;
privacy;
contracts;
quality;
controls;
evidence;
lineage;
retention;
residency;
versioning;
lifecycle.

Governance SHOULD be designed into the product lifecycle rather than added after publication.

6.4.33 Change and Downstream Invalidation

Changes to a Data Product MAY affect:

consumers;
downstream products;
contracts;
policies;
schemas;
quality rules;
controls;
lineage;
regulatory reporting;
AI/ML models.

The architecture SHOULD support impact analysis before materially incompatible change.

Deprecated versions SHOULD remain discoverable for the period required by governance and consumer commitments.

6.4.34 Product Readiness

A profile MAY define readiness criteria before publication.

These MAY include:

owner assigned;
semantics complete;
schema validated;
contract approved;
quality expectations defined;
lineage available;
policy resolved;
access configured;
controls implemented;
observability configured;
lifecycle status approved;
documentation complete.

GEDRA core does not mandate one universal readiness checklist.

6.4.35 Architectural Boundaries

The Data Platform & Product Plane does not own:

enterprise business semantics;
authority designation;
legal/privacy role determination;
consumer business purpose;
infrastructure technology standards.

It MAY implement capabilities supporting these concerns.

6.4.36 Anti-Patterns

The following are Data Platform & Product Plane anti-patterns.

Every Dataset Is a Data Product

Automatically labeling every governed dataset as a Data Product.

Catalog Entry Equals Product

Treating registration in a catalog as sufficient productization.

API Equals Product

Treating an API endpoint as the product itself without product identity, ownership, promise, lifecycle, and governance.

Platform Equals Product

Treating a lakehouse, warehouse, metadata platform, or mesh platform as a Data Product by default.

Product Without Consumer

Creating products without identifiable consumer need or intended use.

Product Without Promise

Calling something a Data Product without explicit consumer-facing commitments.

Copy Equals Product

Treating a replicated or cached copy as a Data Product merely because it is consumable.

Productization by Mandate Only

Forcing every Data Asset through full product obligations regardless of consumer need or value.

Marketplace Dependency

Assuming a marketplace is mandatory for Data Product status.

Observability Equals Control

Treating dashboards or product metrics as Data Controls without defined assurance semantics.

6.4.37 Minimum GEDRA 0.1 Conformance Expectations

An architecture claiming alignment with this plane SHOULD demonstrate that:

Data Object, Data Asset, and Data Product are distinguishable;
Data Product is treated as an intentional specialization of Data Asset;
productization is consumer- and obligation-driven rather than automatic;
platform capabilities are not silently treated as Data Products;
a Data Product has accountable ownership;
a Data Product has explicit identity and lifecycle;
material consumer-facing commitments can be expressed through a Product Promise and/or Data Contract;
output ports are distinguishable from the product itself;
discoverability does not require a marketplace;
metadata, lineage, quality, and observability responsibilities are supported;
authority status remains explicit and is not implied by productization;
policy, controls, and evidence can be integrated into product lifecycle where required;
product changes can be impact-assessed;
business-product and data-product semantics remain distinct.

6.4.38 Illustrative Data Platform & Product View

                     DATA PLATFORM & PRODUCT PLANE

      Platform Capabilities
  ---------------------------------
  Ingestion      Metadata
  Storage        Lineage
  Processing     Quality
  Security       Governance
  Discovery      Observability
  Productization Lifecycle
  ---------------------------------

                |
                v

            Data Asset
   governed valuable data resource
                |
                | intentional productization
                v

            Data Product
  ---------------------------------
  Identity
  Accountable Owner
  Product Promise
  Version
  Lifecycle
  Data Contract
  Output Ports
  Semantics
  Policy / Controls
  Lineage
  Discoverability
  Observability
  ---------------------------------
                |
                v
            Consumers

The platform enables the product but does not define its semantic identity or automatically become the product.

6.5 Consumption & Access Plane

6.5.1 Purpose

The Consumption & Access Plane defines how consumers discover, assess, request, receive, access, and use governed data.

Its purpose is to make explicit:

who or what consumes data;
who merely receives data;
how consumers discover available data;
how suitability for use is assessed;
how access is requested, approved, provisioned, and revoked;
how entitlement and policy obligations are applied;
how consumer class influences quality, latency, lineage, support, compatibility, and productization expectations;
how consumption feedback reaches product and governance processes.

The plane answers questions such as:

Who is the intended consumer?
Is the recipient actually the consumer, or only an intermediary?
What business purpose or use justifies access?
How does the consumer discover the data?
How does the consumer determine whether the data is fit for intended use?
What entitlement, policy, residency, privacy, or contractual obligations apply?
Through what interaction mode is the data consumed?
What consumer obligations must be honored after access is granted?
Does the consumer need a governed Data Product, or is a governed Data Asset sufficient?

6.5.2 Core GEDRM Roles

The Consumption & Access Plane uses the following GEDRM operational roles.

Data Recipient

A party, system, service, or capability that receives data.

Primary question:

Who receives the data?

Receipt does not necessarily imply that the recipient is the ultimate consumer.

Examples:

an intermediary gateway;
a downstream platform;
a regulatory submission service;
a cache;
a processing service;
another Data Product.

Data Consumer

A party, system, service, product, analytical process, or other capability that uses data to achieve an intended outcome.

Primary question:

Who uses the data, and for what purpose?

A Data Consumer may also be a Data Recipient.

However:

Data Recipient
    !=
Data Consumer

in all cases.

A technical intermediary may receive data without being the consumer for whose intended use the data was provided.

6.5.3 Consumer Classes

GEDRA 0.1 recognizes that consumer class materially influences architectural obligations.

Common consumer classes MAY include:

operational;
regulatory;
risk;
finance;
analytics;
AI / ML;
external client;
downstream Data Product;
internal cross-domain consumer;
audit / assurance;
legal / compliance.

These classes are architectural viewpoints rather than mandatory GEDRM core classifications.

A concrete enterprise MAY define a more detailed consumer taxonomy.

6.5.4 Consumer Class and Productization

Different consumers create different obligations.

A governed Data Asset MAY be sufficient where:

consumption is local;
the relationship is tightly coupled;
the consumer population is small and stable;
schema change can be coordinated directly;
support expectations are limited;
discoverability beyond the local context is unnecessary;
lifecycle and compatibility are jointly managed.

Data Product treatment becomes increasingly appropriate where consumers are:

cross-domain;
repeated;
independently evolving;
external;
regulatory;
materially dependent on stable quality or lineage;
downstream products;
AI/ML consumers requiring reproducible semantics;
consumers requiring explicit support, compatibility, or lifecycle commitments.

Therefore:

Consumer need is an important input to productization, but consumer existence alone does not make an asset a product.

6.5.5 Intended Use

The architecture SHOULD capture intended use where it materially affects governance or fitness.

Intended use MAY include:

operational decisioning;
regulatory reporting;
risk calculation;
financial reporting;
customer servicing;
analytics;
model training;
model inference;
fraud detection;
surveillance;
downstream product creation.

Fitness for use is contextual.

Data may be fit for one consumer purpose and unsuitable for another.

6.5.6 Discovery

Consumers SHOULD be able to discover available governed data through appropriate mechanisms.

Discovery MAY be supported by:

catalog;
registry;
marketplace;
semantic search;
product directory;
metadata APIs;
documentation portals;
domain repositories.

Discovery SHOULD expose enough information for the consumer to assess relevance before requesting access where practical.

Useful discovery metadata MAY include:

name;
description;
business semantics;
owner;
product/asset status;
classifications;
lineage;
quality indicators;
authoritative-source context;
freshness;
access method;
contract;
policy;
lifecycle status;
consumer guidance.

6.5.7 Suitability Assessment

Before consumption, a consumer SHOULD be able to assess whether data is suitable for the intended use.

Suitability MAY depend on:

semantic meaning;
authoritative status;
completeness;
accuracy;
timeliness;
freshness;
granularity;
lineage;
scope;
historical depth;
retention;
jurisdiction;
privacy classification;
licensing or contractual limitations;
version compatibility.

A catalog listing alone does not establish fitness for use.

6.5.8 Access

Access is the governed ability to retrieve, receive, query, subscribe to, or otherwise consume data.

Access MAY be:

read
query
subscribe
stream
download
receive
invoke
federate

The access mechanism does not determine whether the underlying thing is a Data Asset or Data Product.

6.5.9 Entitlement

Entitlement determines whether a specific consumer is permitted to access data under defined conditions.

Entitlement MAY consider:

identity;
role;
organization;
business purpose;
jurisdiction;
classification;
contractual status;
subscription;
policy;
approval;
time window;
product tier;
regulatory basis.

Entitlement SHOULD be distinguished from discovery.

A consumer MAY discover a product without being entitled to consume it.

6.5.10 Authentication, Authorization, and Entitlement

GEDRA distinguishes:

Authentication
    = who are you?

Authorization
    = are you permitted to perform this action?

Entitlement
    = are you permitted to consume this governed data/product under these conditions?

Concrete implementations MAY realize authorization and entitlement through the same technical platform.

The semantic responsibilities remain distinguishable.

6.5.11 Access Policy

Access SHOULD respect applicable Data Policy.

Policies MAY constrain:

who may consume;
for what purpose;
from which jurisdiction;
for how long;
at what granularity;
whether redistribution is permitted;
whether data may be persisted;
whether fields must be masked;
whether approval is required.

Policy enforcement MAY be implemented through access gateways, brokers, product runtimes, query services, IAM, or other controls.

6.5.12 Data Contract and Consumer Commitments

Where a governed Data Contract exists, consumers SHOULD be able to understand both provider and consumer obligations.

Consumer obligations MAY include:

permitted use;
redistribution restrictions;
acknowledgment of deprecation;
version adoption;
retention limits;
security requirements;
deletion requirements;
attribution;
feedback or incident reporting.

A Data Contract is not necessarily one-sided.

6.5.13 Consumer Access Patterns

GEDRA supports multiple access patterns.

Direct Access

Consumer
    |
    v
Provider / Authoritative Source

Product Access

Consumer
    |
    v
Data Product Output Port

Brokered Access

Consumer
    |
    v
Data Broker / Marketplace
    |
    v
Provider / Publisher / Data Product

Federated Query

Consumer
    |
    v
Query / Federation Layer
    |
    +--> Source A
    +--> Source B
    +--> Source C

Subscription

Consumer
    |
    | subscribes
    v
Publisher / Broker
    |
    v
Recurring delivery

GEDRA does not prescribe one universal access pattern.

6.5.14 Push and Pull Consumption

Consumption MAY be:

pull-based;
push-based;
query-based;
subscription-based;
event-driven;
file-based;
API-based;
streaming;
batch.

The mode SHOULD be chosen based on consumer and product obligations, not technology preference alone.

6.5.15 Operational Consumers

Operational consumers typically use data to execute or support business processes.

Architectural expectations MAY emphasize:

low latency;
availability;
transactional consistency;
deterministic schema;
operational resilience;
near-real-time state;
clear authority.

A tightly coupled operational consumer MAY be adequately served by a governed Data Asset rather than a full Data Product where broader product obligations are unnecessary.

6.5.16 Regulatory Consumers

Regulatory consumption commonly justifies stronger Data Product treatment because obligations MAY include:

reproducibility;
lineage;
evidence;
semantic stability;
authoritative sourcing;
quality controls;
retention;
version traceability;
support;
controlled change.

A regulatory consumer SHOULD be able to identify which governed source/version produced a submitted or reported result.

6.5.17 Risk and Finance Consumers

Risk and finance consumers MAY require:

reconciled data;
repeatability;
lineage;
historical snapshots;
controlled valuation or calculation inputs;
clear cut-off semantics;
authoritative sourcing;
quality evidence;
consistent classification.

The same Data Asset MAY need different product or contract commitments depending on whether it is used for exploratory analytics versus statutory or financial reporting.

6.5.18 Analytics Consumers

Analytical consumers MAY tolerate greater flexibility in:

schema;
freshness;
exploratory use;
derived datasets.

However, enterprise analytics SHOULD still preserve:

meaning;
provenance;
lineage;
classification;
authority status;
access obligations.

Exploratory use does not remove governance.

6.5.19 AI / ML Consumers

AI/ML consumers MAY use data for:

training;
validation;
testing;
inference;
retrieval augmentation;
feature generation;
monitoring.

The architecture SHOULD consider:

reproducibility;
semantic stability;
training/inference lineage;
data version;
consent/privacy;
policy;
quality;
drift;
feature definition;
permitted use.

AI consumption does not remove existing data governance obligations.

6.5.20 External Consumers

External consumers MAY require stronger product treatment because provider and consumer evolve independently.

Architectural concerns MAY include:

explicit contract;
versioning;
entitlement;
documentation;
support;
usage restrictions;
legal terms;
availability;
compatibility;
deprecation;
metering;
billing where applicable.

External does not necessarily mean commercial.

6.5.21 Downstream Data Products as Consumers

A Data Product MAY consume another Data Product.

For example:

Customer Master Data Product
          |
          v
Payment Lifecycle Data Product
          |
          v
Regulatory Reporting Data Product

Downstream products SHOULD make upstream dependencies visible.

Material upstream changes SHOULD support downstream impact analysis.

6.5.22 Consumer Responsibility for Copies

A consumer MAY create local copies for justified needs such as:

performance;
resilience;
analytics;
historical reproducibility;
workload isolation.

The consumer SHOULD remain accountable for applicable:

retention;
classification;
residency;
security;
synchronization;
redistribution restrictions;
deletion obligations;
authority labeling.

A consumer copy does not become authoritative merely because it is locally preferred.

6.5.23 Consumer-Side Transformation

Consumers MAY transform received data.

Such transformation MAY create Derived Data.

For example:

Consumed payment data
      |
      | aggregate
      v
Liquidity forecast input

The consumer SHOULD preserve lineage where material.

Consumer-side derivation does not change the authority of the source unless separately governed.

6.5.24 Interaction with Semantic & Enterprise Ontology

Consumers SHOULD be able to understand governed meaning.

The semantic plane SHOULD support consumer interpretation through:

definitions;
concept identifiers;
classifications;
relationships;
controlled vocabularies;
external mappings.

A consumer SHOULD NOT infer business meaning solely from a physical field name.

6.5.25 Interaction with Authority Plane

Consumers SHOULD be able to determine relevant authority context.

This MAY include:

System of Record lineage;
Authoritative Source;
Source of Authority;
authoritative scope;
derived status;
historical status;
staleness.

Consumption SHOULD NOT obscure whether data is authoritative, derived, cached, or provisional.

6.5.26 Interaction with Processing, Provision & Movement

The consumption plane receives data through the roles defined in the Processing, Provision & Movement Plane.

For example:

Data Publisher
      |
Data Provider
      |
Data Distributor
      |
Data Recipient / Consumer

A Broker MAY mediate access.

The consumer role remains distinct from the mechanism by which data arrives.

6.5.27 Interaction with Data Platform & Product Plane

The product plane exposes governed Data Assets and Data Products for consumption.

The consumption plane SHOULD provide feedback into:

product demand;
product promise;
interface design;
quality expectations;
support;
lifecycle;
prioritization;
cost allocation.

Consumer need therefore informs product evolution.

6.5.28 Interaction with Governance & Control

Consumption MAY be governed through:

access controls;
entitlement controls;
privacy controls;
retention controls;
purpose limitations;
redistribution controls;
jurisdiction controls;
contractual controls;
usage monitoring.

Evidence MAY be required for sensitive or regulated access.

Examples MAY include:

Consumer identity
Requested product/version
Purpose
Approval
GrantedAt
ExpiresAt
Policy decision
Access outcome

6.5.29 Access Lifecycle

Access SHOULD be lifecycle-managed where required.

A profile MAY define states such as:

Requested
Approved
Provisioned
Active
Suspended
Revoked
Expired

GEDRA core does not mandate these exact states.

The architecture SHOULD support timely revocation where access is no longer justified.

6.5.30 Least Privilege and Minimum Necessary Access

Consumers SHOULD receive only the level of access required for the governed purpose.

This MAY involve:

row filtering;
column masking;
aggregation;
tokenization;
pseudonymization;
purpose-scoped views;
time-bounded access.

The architecture SHOULD avoid indiscriminate broad data access where a narrower governed representation is sufficient.

6.5.31 Purpose Limitation

Where policy or law requires purpose limitation, the architecture SHOULD make intended use explicit enough to support:

entitlement;
policy evaluation;
audit;
control;
revocation.

Access approval for one purpose SHOULD NOT automatically imply permission for unrelated reuse.

6.5.32 Consumer Experience

A mature Consumption & Access Plane SHOULD support a coherent consumer experience.

This MAY include:

searchable discovery;
clear documentation;
semantic definitions;
access instructions;
entitlement status;
quality and freshness information;
lineage;
sample usage;
support channels;
change notifications;
deprecation notices.

Consumer experience SHOULD reduce unnecessary bilateral coordination without weakening governance.

6.5.33 Feedback

Consumers SHOULD be able to provide feedback where appropriate.

Feedback MAY include:

quality issues;
semantic ambiguity;
missing data;
feature requests;
access friction;
performance issues;
demand signals;
support incidents.

Feedback is passed to the Value, Observability & Feedback Plane and MAY drive product or governance changes.

6.5.34 Consumer Impact of Change

Changes to data, semantics, contracts, interfaces, or policies SHOULD be assessed for consumer impact.

Material changes MAY require:

notification;
migration period;
parallel version support;
contract update;
entitlement reevaluation;
retraining;
downstream product changes;
regulatory impact review.

6.5.35 Architectural Boundaries

The Consumption & Access Plane does not own:

semantic definitions;
authority designation;
transformation logic;
product ownership;
policy authorship;
infrastructure implementation.

It consumes and applies those concerns in the context of governed data use.

6.5.36 Anti-Patterns

The following are Consumption & Access Plane anti-patterns.

Recipient Equals Consumer

Assuming the system receiving data is always the ultimate consumer.

Access Equals Understanding

Granting access without sufficient semantic or lineage context to assess appropriate use.

Catalog Equals Entitlement

Assuming discoverability means permission to consume.

One Access Model for All Consumers

Applying identical access patterns and obligations regardless of consumer class.

Consumer Popularity Equals Productization

Productizing data merely because many users happen to query it, without accepting explicit product obligations.

Regulatory Consumer as Ordinary Analytics

Treating regulatory use like exploratory analytics without reproducibility, lineage, and evidence obligations.

Copy Becomes Authority

Allowing consumer-local copies to become de facto authoritative without designation.

Broad Access by Convenience

Granting more data than required because fine-grained access is inconvenient.

Permanent Access by Default

Provisioning indefinite access without lifecycle, review, expiry, or revocation.

Interface-Only Consumer Model

Modeling only APIs, queues, or files while ignoring consumer purpose, class, and obligations.

6.5.37 Minimum GEDRA 0.1 Conformance Expectations

An architecture claiming alignment with this plane SHOULD demonstrate that:

Data Recipient and Data Consumer can be distinguished;
intended consumers and use are identifiable for material data sharing;
consumer class can influence architectural obligations;
discovery and entitlement are distinct;
consumers can assess suitability using appropriate metadata;
access mechanisms do not obscure semantics or authority context;
regulatory and other high-assurance consumers can receive stronger product, lineage, and evidence treatment where required;
local consumer copies retain explicit authority and lineage status;
least-privilege or minimum-necessary access can be applied where appropriate;
purpose limitation can be represented where required;
access can be lifecycle-managed and revoked;
consumer changes and downstream dependencies can be impact-assessed;
consumer feedback can inform product and architecture evolution;
access to data is not treated as equivalent to understanding or permission for unrestricted reuse.

6.5.38 Illustrative Consumption & Access View

                        CONSUMPTION & ACCESS PLANE

                         Discovery
          Catalog / Registry / Marketplace / Search
                              |
                              v
                     Suitability Assessment
            semantics / quality / lineage / authority
                              |
                              v
                       Access Request
                              |
                              v
                         Entitlement
                  policy / purpose / identity
                              |
                              v
                     Governed Consumption
      ------------------------------------------------
      Operational       Regulatory       Risk / Finance
      Analytics         AI / ML          External Client
      Downstream Data Product            Audit / Assurance
      ------------------------------------------------
                              |
                              v
                           Feedback
                              |
                              v
              Value, Observability & Feedback Plane

A consumer may receive data directly, through a Data Product, through a distributor, through a broker, or through a federated query. The plane models the governed consumer relationship rather than mandating one delivery technology.

6.6 Value, Observability & Feedback Plane

6.6.1 Purpose

The Value, Observability & Feedback Plane closes the architectural loop between data provision, consumption, operational behavior, economic accountability, realized value, and continuous evolution.

Its purpose is to make explicit:

how usage and adoption are observed;
how operational behavior is measured;
how cost and economic accountability are understood;
how value is assessed;
how consumer feedback is captured;
how product and architecture decisions are informed by evidence;
how observability signals differ from controls and control evidence;
how downstream outcomes feed back into product, platform, governance, and architecture evolution.

The plane answers questions such as:

Is the data actually being used?
By whom and for what purpose?
Is the product meeting its Product Promise?
What does it cost to operate and consume?
Is the value justified by the cost and complexity?
Which consumers are creating disproportionate cost?
Are freshness, quality, latency, availability, or delivery obligations being met?
What signals indicate degradation?
Which observations are merely metrics, and which form part of governed assurance?
What consumer feedback should trigger product evolution?
Which products or assets should be improved, consolidated, deprecated, or retired?

6.6.2 Core Architectural Responsibilities

The Value, Observability & Feedback Plane SHOULD support architectural treatment of:

usage telemetry;
adoption;
demand;
performance;
availability;
latency;
freshness;
quality signals;
contract conformance signals;
policy enforcement outcomes;
cost;
FinOps;
consumer-level cost attribution;
product economics;
value realization;
consumer satisfaction;
feedback;
incident patterns;
product evolution signals;
lifecycle decisions;
deprecation and retirement evidence;
architecture optimization.

The plane is not limited to dashboards.

Its role is to convert operational and consumer signals into governed architectural insight and, where appropriate, action.

6.6.3 Observability

Observability is the capability to understand the internal state and behavior of data flows, assets, products, and supporting capabilities from available signals.

Signals MAY include:

metrics;
logs;
traces;
lineage events;
quality results;
contract validation results;
access events;
policy decisions;
control outcomes;
distribution status;
consumer usage;
cost records.

Observability SHOULD enable material operational questions to be answered without relying solely on manual investigation.

6.6.4 Observability Dimensions

A GEDRA-aligned architecture MAY observe dimensions including:

Availability

Whether a data capability or product is accessible when required.

Freshness

How recently the data reflects its expected upstream state.

Latency

How long data takes to move, process, publish, or become available.

Completeness

Whether expected data is present.

Quality

Whether governed quality conditions are satisfied.

Volume

How much data is produced, processed, distributed, or consumed.

Reliability

Whether processing and delivery behave consistently over time.

Compatibility

Whether interfaces remain consumable by dependent consumers.

Usage

Who is consuming, how often, and through which interfaces.

Cost

What resources and economic cost are associated with provision and consumption.

Value

What business, regulatory, operational, analytical, or strategic outcomes are enabled.

No single dimension constitutes complete observability.

6.6.5 Metrics Are Not Controls

GEDRA explicitly distinguishes:

Metric
    !=
Data Control

A metric measures or summarizes a condition.

A Data Control is a governed assurance mechanism that prevents, detects, corrects, verifies, or evidences whether a defined obligation or expected state is satisfied.

For example:

Metric:
  payment_data_freshness_seconds = 95

is not by itself a control.

A governed control MAY use that metric:

Control:
  Every 5 minutes,
  verify payment-data freshness <= 120 seconds.
  If breached:
    create evidence,
    alert owner,
    mark product degraded,
    initiate remediation.

The difference lies in governed assurance semantics, not technical implementation.

6.6.6 Dashboards Are Not Controls

A dashboard presents information.

A dashboard MAY display:

metrics;
quality results;
product status;
control outcomes;
cost;
usage;
consumer feedback.

The dashboard itself SHOULD NOT be classified as a Data Control merely because it makes problems visible.

A Data Control requires a defined assurance objective, trigger or frequency, expected state, threshold or rule, ownership, outcome, evidence, and failure or remediation behavior where applicable.

6.6.7 Observability Signal vs Control Evidence

GEDRA distinguishes:

Observability Signal
    = operational information describing system/data behavior

Control Evidence
    = governed artefact substantiating execution or outcome of a Data Control

An observability signal MAY contribute to Control Evidence.

It does not automatically become Control Evidence.

For example:

Raw log event
    -> observability signal

Governed retained evaluation record
    linked to Control CTRL-001
    with threshold, outcome, timestamp, scope
    -> Control Evidence

The same physical record MAY serve multiple semantic purposes where explicitly governed.

6.6.8 Product Promise Observability

A Data Product SHOULD expose sufficient observability to assess whether it is meeting its Product Promise.

Relevant measures MAY include:

freshness;
availability;
latency;
completeness;
quality;
compatibility;
delivery success;
support incidents;
consumer adoption;
deprecation progress.

Observability SHOULD enable the Product Owner to understand whether consumer-facing commitments are being met.

6.6.9 Contract Observability

Where Data Contracts define measurable commitments, the architecture SHOULD support observation of contract conformance.

For example:

Data Contract:
  freshness <= 2 minutes
  completeness >= 99.95%

The plane MAY observe:

Observed freshness
Observed completeness

and pass those signals to Data Controls where governed assurance is required.

Contract conformance SHOULD be version-aware.

6.6.10 Quality Observability

Data Quality Rules MAY generate quality observations.

For example:

Data Quality Rule:
  completeness =
    records_with_required_fields / total_in_scope_records

The resulting value MAY be used for:

operational monitoring;
consumer transparency;
trend analysis;
control evaluation;
product readiness;
incident detection.

The rule, metric, control, and evidence MUST remain semantically distinguishable.

6.6.11 Usage Signals

Usage signals SHOULD enable the architecture to understand actual consumption.

Signals MAY include:

active consumers;
requests;
queries;
subscriptions;
downloaded datasets;
event consumption;
output-port usage;
consumer domain;
product dependency;
access frequency;
volume;
peak usage;
abandoned or unused access.

Usage SHOULD be interpreted in context.

High usage does not automatically mean high value.

Low usage does not automatically mean low value, particularly for regulatory, resilience, or contingency products.

6.6.12 Adoption

Adoption MAY be measured as the extent to which intended consumers use an asset or product.

Examples MAY include:

percentage of target consumers onboarded;
percentage of relevant workloads using governed products;
number of active consuming domains;
migration away from unmanaged copies;
reduction in duplicate sourcing paths.

Adoption measures SHOULD be aligned to strategy rather than treated as vanity metrics.

6.6.13 Cost and FinOps

The plane SHOULD support visibility of data-related cost where material.

Cost MAY include:

compute;
storage;
network;
egress;
streaming;
query;
orchestration;
model execution;
support;
operational labor;
observability;
control execution;
retention.

Cost SHOULD be attributable at a useful level where possible.

This MAY include:

platform
domain
Data Product
consumer
workload
output port

6.6.14 Consumer Cost Attribution

Where one consumer or workload creates disproportionate cost, GEDRA supports explicit consumer cost attribution.

For example:

Data Product
   |
   +-- Consumer A: 10% usage / 5% cost
   +-- Consumer B: 20% usage / 15% cost
   +-- Consumer C: 70% usage / 80% cost

This MAY inform:

optimization;
caching;
workload isolation;
pricing or chargeback;
cost-sharing;
alternative access pattern;
product redesign.

Economic accountability SHOULD NOT be confused with semantic ownership.

6.6.15 Value

Value is the benefit realized from governed data use.

Value MAY be:

financial;
regulatory;
operational;
risk-reducing;
customer-facing;
analytical;
strategic;
productivity-related;
resilience-related.

GEDRA does not require all value to be expressed as financial ROI.

Examples:

Regulatory reporting:
  value = compliance + reproducibility + reduced reporting risk

Fraud detection:
  value = prevented loss + faster detection

Operational product:
  value = reduced processing delay + lower failure rate

Reference data:
  value = consistency + reduced duplication + lower reconciliation cost

6.6.16 Value Measurement

Value SHOULD be assessed against intended outcomes.

Possible measures MAY include:

revenue enabled;
cost avoided;
risk reduced;
regulatory obligations satisfied;
processing time reduced;
manual effort removed;
consumer onboarding time reduced;
duplicate pipelines retired;
data-quality incidents reduced;
model performance improved;
customer experience improved.

A value metric SHOULD state what outcome it represents.

6.6.17 Value vs Usage

GEDRA distinguishes:

Usage
    = extent of consumption

Value
    = benefit realized

The two may correlate but are not equivalent.

For example:

Low-frequency regulatory dataset
    -> low usage
    -> high value

High-volume exploratory dataset
    -> high usage
    -> uncertain value

Architecture decisions SHOULD therefore avoid using usage alone as a proxy for value.

6.6.18 Feedback

Feedback is information from consumers, operators, owners, governance bodies, or automated observations that may influence evolution.

Feedback MAY include:

data-quality issue;
semantic ambiguity;
missing field;
access friction;
latency complaint;
feature request;
documentation gap;
cost concern;
contract mismatch;
support incident;
deprecation objection;
product enhancement request.

Feedback SHOULD be traceable to the affected Data Asset, Data Product, interface, contract, or architectural capability where possible.

6.6.19 Feedback Loop

GEDRA defines the following general feedback loop:

Consumption
    |
    v
Usage / Operational Signals
    |
    v
Observability
    |
    +--> Cost
    +--> Quality
    +--> Contract Performance
    +--> Consumer Feedback
    +--> Value
    |
    v
Assessment
    |
    v
Product / Platform / Governance / Architecture Change
    |
    v
New Version / New Capability / Retirement

The loop MAY operate continuously or periodically.

6.6.20 Feedback Into Product Evolution

Product Owners SHOULD use relevant feedback and observability to inform:

backlog;
prioritization;
quality improvement;
interface design;
Product Promise;
support model;
capacity;
lifecycle;
deprecation;
retirement.

Consumer feedback does not automatically override governance or strategy.

6.6.21 Feedback Into Platform Evolution

Platform teams MAY use aggregated signals to inform:

capacity;
runtime optimization;
tooling;
self-service capability;
metadata coverage;
lineage quality;
control automation;
observability capability;
cost optimization.

Platform evolution SHOULD remain driven by architectural need rather than isolated technology preference.

6.6.22 Feedback Into Governance

Governance bodies MAY use signals to identify:

recurring quality failures;
policy breaches;
weak ownership;
stale assets;
unmanaged copies;
excessive exception rates;
repeated control failures;
consumer confusion;
authority ambiguity.

These signals MAY trigger:

policy change;
stronger controls;
ownership review;
remediation;
architecture review;
product retirement;
requirement refinement.

6.6.23 Feedback Into Architecture

Architecture SHOULD evolve based on evidence.

Examples MAY include:

repeated point-to-point duplication suggests a reusable distribution pattern;
high-cost heavy consumers justify specialized access patterns;
recurring semantic mismatch suggests stronger ontology alignment;
widespread use of non-authoritative copies suggests authority or sourcing redesign;
frequent contract breakage suggests stronger versioning and compatibility policy.

GEDRA therefore treats feedback as an architectural input rather than merely an operational concern.

6.6.24 Incident and Problem Signals

Operational incidents MAY reveal structural architecture weaknesses.

The plane SHOULD support distinction between:

Incident
    = observed service/data failure

Problem
    = underlying recurring or systemic cause

Repeated incidents SHOULD inform root-cause and architecture analysis where appropriate.

6.6.25 Degradation

A Data Product or capability MAY be considered degraded where measured behavior falls outside expected operating conditions without being fully unavailable.

Examples:

freshness breach;
reduced completeness;
delayed delivery;
partial source outage;
elevated error rate;
quality deterioration.

A profile MAY define explicit degraded states and consumer-notification rules.

GEDRA core does not mandate one state model.

6.6.26 Product Health

Product health SHOULD be considered multidimensional.

A product can be:

technically available;
semantically valid;
contractually compliant;
economically inefficient;
poorly adopted;
low value;
operationally unstable.

A single “green” status SHOULD NOT conceal materially different dimensions.

6.6.27 Lifecycle Decision Support

Observability and value signals MAY inform lifecycle decisions such as:

continue
invest
optimize
consolidate
deprecate
retire

Retirement SHOULD consider:

active consumers;
contractual obligations;
regulatory retention;
downstream dependencies;
migration status;
replacement availability.

6.6.28 Reproducibility

Where evidential or regulatory obligations require reproducibility, the plane SHOULD support retrieval of historical context such as:

product version;
contract version;
policy version;
rule version;
control version;
source version or snapshot;
lineage;
processing time;
observed outcome.

Observability data MAY contribute to this context but MUST NOT substitute for governed evidence where evidence is required.

6.6.29 Interaction with Semantic & Enterprise Ontology

Observability SHOULD use governed semantic identifiers where useful.

For example, a quality metric attached to:

Payment.amount

is more meaningful than one attached only to:

table_17.column_c

Semantic alignment improves cross-system observability and impact analysis.

6.6.30 Interaction with Authority Plane

The plane SHOULD observe authority-relevant signals where useful.

Examples MAY include:

consumers sourcing from non-authoritative copies;
stale authoritative-source projections;
authority migration status;
discrepancies between Systems of Record and Authoritative Sources;
unauthorized sourcing paths.

Observability does not establish authority.

It reveals behavior around authority.

6.6.31 Interaction with Processing, Provision & Movement

The plane SHOULD observe material processing and movement behavior.

Signals MAY include:

processing duration;
transformation failure;
message delay;
distribution failure;
retry;
replay;
schema rejection;
broker denial;
cross-boundary transfer;
contract breach.

These signals MAY feed product and control decisions.

6.6.32 Interaction with Data Platform & Product

The plane provides product health, adoption, cost, value, and feedback information.

It SHOULD support Product Owners and platform owners in determining:

whether Product Promise is being met;
which consumers are active;
where cost is concentrated;
whether changes are improving outcomes;
whether the product remains justified.

6.6.33 Interaction with Consumption & Access

Consumer behavior is a major input.

Signals MAY include:

discovery;
access request;
approval;
first use;
recurring use;
abandoned access;
entitlement expiry;
support request;
feedback;
consumer migration.

Privacy and policy requirements MAY restrict how consumer telemetry is collected or retained.

6.6.34 Interaction with Governance & Control

This plane has a particularly important boundary with Governance & Control.

Observability provides signals.

Controls evaluate governed expectations.

Control Evidence substantiates the control outcome.

The preferred relationship is:

Observability Signal
        |
        v
Data Quality Rule / Evaluation
        |
        v
Data Control
        |
        v
Control Execution
        |
        v
Control Evidence

Not every signal requires a control.

Not every metric requires evidence.

Controls SHOULD be introduced where assurance is justified by risk, policy, contract, regulation, product promise, or other governed requirement.

6.6.35 Alerts

Alerts MAY notify relevant actors that a defined condition has occurred.

An alert MAY be generated from:

threshold breach;
control failure;
quality issue;
cost spike;
availability loss;
contract breach;
policy denial.

An alert is not automatically a Data Control.

It MAY be an action within a control response.

6.6.36 SLOs, SLIs, and Product Commitments

Profiles MAY use constructs such as:

Service Level Indicator;
Service Level Objective;
Service Level Agreement.

GEDRA core does not mandate these terms.

Where used, they SHOULD map clearly to the relevant Product Promise, Data Contract, operational metric, or control.

For example:

SLI:
  observed freshness

SLO:
  99.9% of observations <= 120 seconds

Product Promise:
  freshness <= 2 minutes

Control:
  detect and evidence material breach

6.6.37 Cost Is Not Value

GEDRA explicitly distinguishes:

Cost
    !=
Value

Low cost does not imply high value.

High cost does not imply low value.

Architecture SHOULD evaluate cost relative to purpose, obligation, and realized outcome.

6.6.38 Optimization

Optimization MAY target:

cost;
latency;
resilience;
freshness;
quality;
consumer onboarding;
duplicate movement;
storage;
control efficiency;
platform utilization.

Optimization SHOULD NOT compromise semantic integrity, authority, regulatory obligations, product promise, or control effectiveness without explicit governance.

6.6.39 Architectural Boundaries

The Value, Observability & Feedback Plane does not own:

semantic definitions;
authority designation;
transformation logic;
product ownership;
policy authorship;
consumer entitlement;
control semantics.

It observes and informs those concerns.

6.6.40 Anti-Patterns

The following are Value, Observability & Feedback Plane anti-patterns.

Dashboard Equals Governance

Assuming governance exists because dashboards exist.

Metric Equals Control

Treating a measurement as a control without assurance semantics.

Log Equals Evidence

Treating raw logs as Control Evidence without governance, retention, linkage, and outcome semantics.

Usage Equals Value

Assuming the most frequently used data is automatically the most valuable.

Cost Equals Value

Reducing product value to infrastructure cost alone.

Green Dashboard Means Healthy Product

Collapsing semantic, quality, contract, adoption, value, and economic health into one status.

Feedback Without Ownership

Collecting feedback without an accountable owner or decision path.

Observability Without Actionability

Collecting large volumes of telemetry that cannot inform decisions or remediation.

Control Everything

Turning every metric or observation into a formal control regardless of risk or obligation.

Optimize Away Governance

Reducing cost or latency by bypassing required semantics, controls, lineage, or authority.

6.6.41 Minimum GEDRA 0.1 Conformance Expectations

An architecture claiming alignment with this plane SHOULD demonstrate that:

material usage and operational behavior can be observed;
metrics are distinguishable from Data Controls;
observability signals are distinguishable from Control Evidence;
product health can be assessed against relevant Product Promise or contract commitments;
usage and value are not assumed equivalent;
cost and value are not assumed equivalent;
consumer feedback can be associated with affected assets, products, or interfaces;
relevant feedback can influence product, platform, governance, or architecture evolution;
product lifecycle decisions can consider active consumers and downstream dependencies;
regulatory or evidential use can retain reproducibility context where required;
optimization does not silently bypass governance or authority obligations;
observability is treated as a decision-support capability rather than merely a dashboard layer.

6.6.42 Illustrative Value, Observability & Feedback View

                   VALUE, OBSERVABILITY & FEEDBACK PLANE

                       Consumption
                           |
                           v
              +-------------------------+
              |      Usage Signals      |
              +-------------------------+
                           |
             +-------------+-------------+
             |             |             |
             v             v             v
      Observability      Cost          Feedback
    freshness/quality    FinOps       consumers
    latency/availability                operators
             |             |             |
             +-------------+-------------+
                           |
                           v
                    Value Assessment
                           |
        +------------------+------------------+
        |                  |                  |
        v                  v                  v
   Product Change     Platform Change    Governance /
   version/evolve     optimize/scale      Architecture
        |                                      |
        +------------------+-------------------+
                           |
                           v
                       New State

The plane closes the loop. It does not replace governance, controls, or ownership; it supplies evidence and signals that allow those mechanisms to act intelligently.

7. Cross-Cutting Governance & Control Model

7.1 Purpose

The Cross-Cutting Governance & Control Model defines how governance obligations, accountability, policy, privacy, security, quality, lifecycle, control, evidence, and exception management apply across all GEDRA planes.

Its purpose is to ensure that governance is not modeled as a downstream approval stage or as a separate administrative layer detached from data architecture.

Instead, governance and control are architectural responsibilities that shape semantic definitions, establish authority, constrain processing and movement, govern assets and products, regulate access and consumption, observe outcomes, produce assurance evidence, and drive remediation and evolution.

The model answers questions such as:

Who is accountable for the data, product, policy, or control?
Which obligations apply?
How are those obligations translated into contracts, rules, controls, and executable policy?
Where are controls executed?
What evidence demonstrates that controls operated?
How are exceptions governed?
How are failures escalated and remediated?
How are policy changes propagated to products, consumers, and runtime enforcement?
How can an enterprise demonstrate that expected data governance is operating rather than merely documented?

7.2 Cross-Cutting Nature

Governance and control apply across every GEDRA plane.

Semantic & Enterprise Ontology
Authority
Processing, Provision & Movement
Data Platform & Product
Consumption & Access
Value, Observability & Feedback
        |
        +-----------------------------------+
        | Cross-Cutting Governance & Control|
        +-----------------------------------+

The governance model MUST NOT be interpreted as a seventh sequential processing stage.

A governance responsibility MAY apply before, during, or after data creation, transformation, publication, consumption, or retirement.

7.3 Core Governance Domains

GEDRA 0.1 identifies the following cross-cutting governance domains:

ownership;
stewardship;
classification;
policy;
privacy;
security;
access;
contracts;
quality;
metadata;
lineage;
lifecycle;
retention;
residency;
versioning;
observability;
economic accountability;
controls;
evidence;
exceptions;
remediation;
assurance.

These domains MAY be implemented through centralized, federated, delegated, or hybrid operating models.

GEDRA does not mandate one organizational model.

7.4 Core GEDRM Governance Concepts

Data Owner

An accountability role responsible for governed data within a defined scope.

The Data Owner SHOULD be able to make or sponsor decisions concerning meaning, classification, authoritative sourcing, access, retention, quality expectations, productization, lifecycle, and policy applicability.

Ownership MUST be scoped.

Data Steward

An accountability role supporting the definition, interpretation, quality, governance, and ongoing management of data.

A Data Steward does not automatically replace the Data Owner's accountability.

Data Custodian

A governance or operational role responsible for the safekeeping, handling, administration, or protection of data on behalf of the accountable owner or governing authority.

Custodianship does not imply ownership or semantic authority.

Data Product Owner

An accountability role responsible for the governed consumer-facing Data Product.

The Data Product Owner is accountable for the product lifecycle and Product Promise.

Control Owner

An accountability role responsible for a Data Control.

The Control Owner SHOULD ensure that the control objective remains valid, the control is designed appropriately, it executes as required, failures are handled, and evidence is retained where required.

Source of Authority

A governance actor or normative basis that establishes or mandates authority for a defined data scope.

Source of Authority participates in the Authority Plane but is also part of the governance model because authority designation is itself a governed decision.

7.5 Governance Artefact Chain

GEDRA adopts the following conceptual governance chain:

Requirement / Regulation / Obligation
                |
                v
           Data Policy
                |
                +-------------------------+
                |                         |
                v                         v
        Data Contract              Policy as Code
                |                         |
                v                         v
       Data Quality Rule          Runtime Enforcement
                |
                v
           Data Control
                |
                v
        Control Execution
                |
                v
        Control Evidence

This is a reference pattern, not a mandatory linear chain.

For example:

Policy -> Control

is valid where no Data Quality Rule is required.

Likewise:

Product Promise -> Data Control

may be valid where the control assures a consumer-facing commitment.

7.6 Data Policy

A Data Policy is the governed normative artifact stating what MUST, SHOULD, MAY, or MUST NOT be true regarding data management or use.

Policy MAY address ownership, authoritative sourcing, classification, privacy, access, residency, retention, quality, publication, distribution, productization, lifecycle, evidence, and security.

Data Policy answers:

What obligation, permission, prohibition, principle, or constraint applies?

A policy is not the same thing as its runtime implementation.

7.7 Policy as Code

Policy as Code is an executable representation of resolved applicable policy.

GEDRA requires:

Data Policy != Policy as Code

Policy remains the normative source.

Policy as Code is the executable form used by runtime capabilities and SHOULD be traceable to source policy, policy version, scope, effective period, approval, and applicability decision.

Policy as Code is not automatically a Data Control.

7.8 Data Contract

A Data Contract defines governed interaction commitments at a provider, publisher, Data Product, or consumer boundary.

It MAY include semantic commitments, schema, compatibility, freshness, completeness, availability, usage rules, lifecycle, deprecation, and consumer obligations.

GEDRA requires:

Data Contract != Data Policy
Data Contract != Data Quality Rule
Data Contract != Data Control

A contract MAY implement policy obligations, but it MAY also contain product-specific commitments that do not originate from enterprise policy.

7.9 Data Quality Rule

A Data Quality Rule defines how a specified data-quality condition is evaluated.

A rule may produce a measurement or evaluation result.

GEDRA requires:

Data Quality Rule != Data Control

A rule evaluates.

A control assures.

7.10 Data Control

A Data Control is a governed assurance mechanism used to prevent, detect, correct, verify, or evidence whether a defined expectation is satisfied.

A Data Control SHOULD normally define:

control objective;
governed expectation;
scope;
trigger or frequency;
expected state;
rule or threshold;
Control Owner;
execution behavior;
failure response;
evidence requirement;
exception handling;
escalation or remediation where applicable.

Controls MAY be preventive, detective, corrective, automated, manual, or semi-automated.

7.11 Data Quality Control Pattern

For GEDRA architectural reasoning, Data Quality Control is an architectural specialization pattern of Data Control: a Data Control that uses one or more Data Quality Rules to assure a governed quality expectation.

Data Quality Control is not introduced by GEDRA 0.1 as a new GEDRM core concept. Where an enterprise or profile formalizes it as a named subtype, that specialization MUST remain compatible with GEDRM Data Control semantics.

For example:

Policy:
  Regulatory payment data must be complete.

Contract:
  completeness >= 99.95%

Data Quality Rule:
  complete_records / total_records

Data Quality Control pattern:
  evaluate every 5 minutes;
  fail if < 99.95%;
  create evidence;
  alert owner;
  initiate remediation.

The rule and the control remain distinct.

7.12 Control Execution

Control Execution is the activity in which a Data Control is performed for a defined scope and point or period in time.

A Control Execution MAY capture:

control identifier;
execution identifier;
execution time;
evaluated scope;
product or data version;
rule version;
policy version;
contract version;
observed values;
outcome;
exception;
remediation reference.

Control Execution provides the runtime bridge between control definition and Control Evidence.

7.13 Control Evidence

Control Evidence is the governed artifact that substantiates execution, outcome, exception, remediation, approval, or effectiveness of a Data Control.

GEDRA distinguishes:

Metric != Control Evidence
Log != Control Evidence
Observability Signal != Control Evidence
Audit Record != Control Evidence

although one physical record MAY serve more than one semantic role where explicitly governed.

Control Evidence SHOULD be retained and protected according to its evidential purpose.

7.14 Evidence Minimum Semantics

Where Control Evidence is required, it SHOULD be possible to identify at least:

the Data Control;
the execution, where modeled;
evaluated scope;
time;
outcome.

Depending on risk and obligation, evidence MAY additionally include expected condition, observed value, threshold, input population, policy version, rule version, contract version, product version, exception, remediation, approver, evidence location, and retention period.

7.15 Controls Are Not Requirements

GEDRA requires:

Requirement = what is required
Control = how assurance is operationally achieved

A control SHOULD trace to a governed expectation such as policy, contract, Product Promise, regulation, external requirement, or architecture decision.

7.16 Requirement Traceability

GEDRA follows GEDRM 0.1 in treating generic Data Requirement as external/reference traceability rather than a first-class core semantic hierarchy.

A traceability chain MAY be:

Requirement Reference
        |
        v
     Data Policy
        |
        v
    Data Control
        |
        v
 Control Evidence

7.17 Governance Applicability

Governance obligations SHOULD be resolved against context.

Applicability MAY depend on:

data classification;
semantic concept;
jurisdiction;
consumer;
purpose;
product;
authority scope;
lifecycle stage;
regulatory regime;
contractual terms.

GEDRA SHOULD avoid assuming that one universal policy set applies identically to every data flow.

7.18 Policy Resolution

A platform or productization process MAY resolve applicable policy before runtime.

Enterprise Policies
Domain Policies
Regulatory Obligations
Product-Specific Policies
        |
        v
Applicability Resolution
        |
        v
Resolved Governance Bundle
        |
        +-- Policy as Code
        +-- Data Contract
        +-- Data Quality Rules
        +-- Data Controls
        +-- Provenance

This supports deterministic runtime behavior and reproducibility.

7.19 Product-Local Governance

GEDRA supports product-local execution of resolved governance.

For example:

Data Product Version 2.4
    |
    +-- Contract v3
    +-- Policy Bundle v7
    +-- DQ Rules v5
    +-- Controls v4

Runtime evaluation MAY occur locally to the product or its supporting platform.

The architecture SHOULD NOT require every transaction to invoke a central policy service merely to rediscover already-resolved policy.

Central or federated policy services MAY remain authoritative for policy authoring, lifecycle, applicability, approval, versioning, and change propagation.

7.20 Ownership and Accountability

Each material governed concern SHOULD have appropriate accountable ownership.

Examples:

Data Asset -> Data Owner
Data Product -> Data Product Owner
Data Control -> Control Owner
Authority Designation -> Source of Authority

Accountability SHOULD be explicit enough to support decision-making and escalation.

7.21 Ownership Does Not Imply Every Operational Role

GEDRA distinguishes accountability from operational execution.

A Data Owner need not operate the platform, transform the data, publish every interface, administer access, or execute every control.

Likewise, a Data Custodian or platform operator does not become the Data Owner merely because it manages the data operationally.

7.22 Classification Governance

Classification SHOULD be governed across the relevant GEDRM dimensions.

Examples include:

Business/Semantic;
Provenance;
Processing/Governance State;
Legal/Sensitivity.

Classification SHOULD influence access, retention, residency, security, product obligations, control requirements, and consumer restrictions.

The architecture SHOULD classify at the smallest meaningful governed scope.

7.23 Privacy Governance

Where Personal Data is involved, governance SHOULD be able to represent:

Personal Data classification;
Processing Activity;
Data Controller;
Data Processor;
purpose;
governing basis where applicable;
retention;
access;
transfer restrictions;
evidence.

The legal/privacy role model MUST remain distinct from operational data-flow roles.

Data Transformer != Data Processor

although one capability MAY simultaneously perform both roles in context.

7.24 Security Governance

Security responsibilities MAY include confidentiality, integrity, availability, identity, authentication, authorization, encryption, key management, segregation, monitoring, and incident response.

GEDRA does not define a complete security architecture.

Security capabilities SHOULD be integrated with data classifications, policy, access, and control requirements.

7.25 Access Governance

Access governance SHOULD determine who may access, what they may access, for what purpose, under which conditions, for how long, and whether redistribution or persistence is allowed.

7.26 Retention and Lifecycle Governance

Retention SHOULD be governed according to applicable law, regulation, policy, contract, business need, product lifecycle, and evidential need.

The architecture SHOULD distinguish active use, historical retention, archival, legal hold, deletion, and product retirement.

7.27 Residency Governance

Residency requirements SHOULD specify where data may or must be stored, processed, replicated, backed up, or transmitted.

A residency policy MAY be assured directly by a Data Control without requiring a Data Quality Rule.

Policy:
  Personal Data for jurisdiction X must remain in approved regions.

Control:
  Validate storage and processing region against approved set.

Evidence:
  actualRegion = UK
  expectedRegions = [UK]
  outcome = PASS

This illustrates why Data Quality Rule is not a mandatory intermediary for every control.

7.28 Lineage Governance

Lineage SHOULD be governed according to use and risk.

Material lineage MAY support authority, impact analysis, regulatory reporting, reproducibility, product dependency, quality investigation, AI/ML provenance, and consumer transparency.

7.29 Metadata Governance

Metadata SHOULD be governed sufficiently to support identification, ownership, semantics, classification, authority, lineage, quality, policy, product discovery, lifecycle, and control traceability.

Metadata governance SHOULD avoid becoming a catalog-only exercise.

7.30 Version Governance

Version governance MAY apply to policies, contracts, schemas, semantic models, Data Products, Data Quality Rules, Data Controls, executable policy, and evidence models.

Versions SHOULD be linked where reproducibility depends on their exact combination.

7.31 Exception Management

A governance model SHOULD support controlled exceptions where obligations cannot be satisfied normally.

An exception SHOULD identify:

governed expectation;
affected scope;
rationale;
risk;
approver;
start time;
expiry or review date;
compensating control where applicable;
remediation plan;
status.

Exceptions MUST NOT silently redefine the underlying policy or requirement.

7.32 Remediation and Escalation

A control failure SHOULD trigger a defined response where warranted.

Remediation MAY include correction, reprocessing, source repair, consumer notification, access restriction, publication suspension, rollback, escalation, or permanent architecture change.

Governance SHOULD provide escalation paths when ownership is unclear, policy cannot be satisfied, authority is disputed, control failures persist, product obligations are breached, regulatory risk exists, or exceptions exceed tolerated duration.

7.33 Preventive, Detective, and Corrective Controls

GEDRA recognizes:

Preventive — attempts to stop an undesired state before it occurs.
Detective — identifies that an undesired state has occurred.
Corrective — restores or remediates expected state.

One control design MAY contain multiple mechanisms.

7.34 Automated and Manual Controls

Controls MAY be automated, manual, or semi-automated.

Manual does not mean weak.

Automated does not mean effective.

Control effectiveness depends on design, execution, evidence, ownership, and response.

7.35 Control Effectiveness

Where required, control effectiveness MAY be assessed separately from individual execution.

Questions MAY include:

Is the control designed appropriately?
Is it operating at the intended frequency?
Does it detect or prevent the target failure?
Are failures remediated?
Is evidence complete?
Is the control still needed?

A passing execution does not by itself prove long-term effectiveness.

7.36 Governance by Design

GEDRA favors governance embedded in architecture and lifecycle over governance added after implementation.

Examples include:

semantics defined before publication;
authority designated before broad consumption;
policy resolved during productization;
controls defined with product commitments;
entitlement integrated into access;
lineage captured during processing;
lifecycle and retention encoded into asset/product management.

7.37 Federated and Centralized Governance

GEDRA supports centralized, federated, and hybrid governance.

A typical federated pattern MAY be:

Enterprise Governance
    |
    +-- enterprise policy
    +-- common semantic standards
    +-- control expectations
    |
    v
Domain Governance
    |
    +-- domain semantics
    +-- domain ownership
    +-- local policy specialization
    |
    v
Product / Platform Governance
    |
    +-- runtime implementation
    +-- evidence
    +-- consumer commitments

Federation SHOULD preserve traceability and avoid incompatible local redefinition of core semantics.

7.38 Governance Across GEDRA Planes

Semantic Plane

Governance applies to definitions, ownership, classifications, taxonomies, mappings, and semantic evolution.

Authority Plane

Governance applies to authority designation, scope, effective period, Source of Authority, and migration.

Processing, Provision & Movement

Governance applies to transformations, movement, publication, distribution, residency, masking, and redistribution.

Data Platform & Product

Governance applies to assets, productization, Product Promise, contracts, lifecycle, ownership, and controls.

Consumption & Access

Governance applies to entitlement, purpose, access, retention, consumer obligations, and revocation.

Value, Observability & Feedback

Governance applies to metric definitions, evidence, controls, retention, escalation, remediation, and lifecycle decisions.

7.39 Governance Interaction Model

External Requirement / Regulation / Business Obligation
                         |
                         v
                    Data Policy
                         |
                applicability resolution
                         |
          +--------------+--------------+
          |              |              |
          v              v              v
   Data Contract   Policy as Code   DQ / Other Rules
          |              |              |
          +--------------+--------------+
                         |
                         v
                    Data Control
                         |
                         v
                  Control Execution
                         |
                         v
                  Control Evidence
                         |
                         v
               Assurance / Governance
                         |
                +--------+--------+
                |                 |
                v                 v
           Remediation        Exception
                |                 |
                +--------+--------+
                         |
                         v
                  Architecture /
                  Product Change

Not every governed obligation requires every element in this chain.

7.40 Governance Change Propagation

Changes to governed artifacts MAY require downstream propagation.

For example:

Policy Change
    |
    +--> applicability reassessment
    +--> Policy as Code regeneration
    +--> Data Contract review
    +--> Control review
    +--> product version impact
    +--> consumer impact
    +--> evidence model impact

The architecture SHOULD support impact analysis before a material governance change becomes effective.

7.41 Governance Currentness

Governed artifacts SHOULD have identifiable currentness.

This MAY include current version, effective-from, effective-to, superseded-by, deprecated, withdrawn, and review date.

Runtime capabilities SHOULD be able to determine which governed version applies to a given execution or product version where material.

7.42 Evidence Retention and Auditability

Control Evidence SHOULD be retained according to regulatory requirement, policy, risk, audit need, product lifecycle, legal hold, and evidential purpose.

A GEDRA-aligned architecture SHOULD support auditability for material governance decisions, including who approved, what changed, when, why, previous state, resulting state, impacted scope, and evidence.

Auditability does not require one universal audit platform.

7.43 Governance Observability

Governance itself SHOULD be observable where useful.

Signals MAY include:

unowned assets;
stale policies;
expired exceptions;
failed controls;
overdue remediation;
missing lineage;
unresolved authority;
product contract breaches;
policy propagation backlog.

Governance observability SHOULD support action, not merely reporting.

7.44 Economic Accountability

Economic accountability MAY be governed where data cost is material.

This MAY include product cost, consumer cost, platform cost, heavy-consumer attribution, and optimization targets.

Economic governance SHOULD NOT override mandatory regulatory, security, or evidential obligations without explicit risk acceptance.

7.45 Architectural Boundaries

The Cross-Cutting Governance & Control Model does not prescribe one governance organization, workflow engine, policy platform, catalog, control framework, security product, or evidence store.

It defines architectural responsibilities and semantic distinctions that implementations MUST preserve.

7.46 Anti-Patterns

The following are Governance & Control anti-patterns:

Governance as Final Approval — governance applied only after architecture and implementation are complete.
Policy Equals Control — treating a normative policy statement as an assurance mechanism.
Rule Equals Control — treating a validation rule as a control without ownership, trigger, outcome, evidence, and response.
Dashboard Equals Control — treating visibility as assurance.
Log Equals Evidence — treating raw logs as evidential artifacts without governance.
Control Without Owner — operating a control without accountable ownership.
Evidence Without Control — retaining records called control evidence without identifying the control they substantiate.
Exception Becomes Policy — allowing long-running exceptions to silently redefine the governing expectation.
Central Policy Lookup Per Transaction by Default — rediscovering already-resolved policy centrally for every transaction without architectural need.
Governance Tool Equals Governance Model — assuming deployment of a catalog, policy engine, or control platform establishes governance by itself.
Ownership by Operations — assuming the team operating the platform automatically owns the data.
Compliance by Documentation — assuming documented policy or architecture proves operational compliance.

7.47 Minimum GEDRA 0.1 Conformance Expectations

An architecture claiming alignment with the Cross-Cutting Governance & Control Model SHOULD demonstrate that:

governance applies across all GEDRA planes rather than only downstream;
material Data Assets and Data Products have accountable ownership;
Data Controls have Control Owners;
Data Policy, Policy as Code, Data Contract, Data Quality Rule, Data Control, and Control Evidence are distinguishable;
controls can trace to governed expectations;
Control Evidence can identify the control it substantiates;
observability metrics and dashboards are not automatically treated as controls;
exceptions are explicit and governed;
remediation and escalation can occur where obligations fail;
authority designation is governed and scoped;
classification can drive access, retention, residency, security, and control obligations;
privacy roles remain distinct from technical operational roles;
governance artifacts are versionable and currentness can be determined where required;
material policy changes can be impact-assessed and propagated;
product-local executable governance can remain traceable to authoritative policy;
governance tool choices do not redefine GEDRM/GEDRA semantics.

7.48 Illustrative Cross-Cutting Governance & Control View

                    CROSS-CUTTING GOVERNANCE & CONTROL

  Ownership   Stewardship   Classification   Policy   Privacy
      |            |              |            |        |
      +------------+--------------+------------+--------+
                                   |
                                   v
                       Governed Expectations
                                   |
                  +----------------+----------------+
                  |                |                |
                  v                v                v
             Contracts       Policy as Code       Rules
                  \                |                /
                   \               |               /
                    +--------------+--------------+
                                   |
                                   v
                              Data Control
                                   |
                                   v
                           Control Execution
                                   |
                                   v
                           Control Evidence
                                   |
                  +----------------+----------------+
                  |                                 |
                  v                                 v
             Assurance                         Exception /
             Reporting                         Remediation

 Applies across:
 Semantics | Authority | Processing | Product | Consumption | Feedback

The model is architectural and semantic. Its physical realization may be centralized, federated, embedded in products, implemented through shared platforms, or distributed across multiple enterprise capabilities.

8. Technology / Utility Foundation

8.1 Purpose

The Technology / Utility Foundation defines the enabling technical capabilities required to realize GEDRA-aligned data architectures.

Its purpose is to make explicit the distinction between:

data architecture responsibilities;
reusable technical capabilities;
platform runtime services;
infrastructure services;
implementation choices.

The foundation supports all GEDRA planes but MUST NOT be mistaken for the data architecture itself.

It answers questions such as:

Which technical capabilities enable the architecture?
Which concerns belong to infrastructure rather than data semantics?
Which platform capabilities may be shared across planes?
How should runtime services support reliability, security, resilience, observability, and automation?
How can technology evolve without redefining GEDRA roles or semantics?

8.2 Foundational Principle

GEDRA adopts the principle:

Technology enables data architecture but does not define it.

A warehouse, lakehouse, database, cloud platform, event bus, API gateway, catalog, policy engine, or AI runtime does not by itself define the enterprise data architecture.

Architecture SHOULD therefore be expressible independently of vendor or product name.

For example:

Data Distributor
    = GEDRM/GEDRA role

Kafka
    = possible implementation technology

and:

Authoritative Source
    = governed data role

BigQuery
    = possible physical realization

Technology MUST NOT be used as a substitute for semantic or architectural role.

8.3 Foundation Scope

The Technology / Utility Foundation MAY include:

compute;
storage;
networking;
identity and access management;
messaging;
API infrastructure;
orchestration;
workflow;
CI/CD;
configuration management;
secrets and key management;
runtime hosting;
container/platform runtime;
backup and disaster recovery;
observability tooling;
scheduling;
service discovery;
policy enforcement runtime;
metadata infrastructure;
AI orchestration;
cryptographic services;
environment management.

GEDRA core does not mandate one technology stack.

8.4 Compute

Compute provides execution capacity for data processing and supporting services.

Compute MAY include:

virtual machines;
containers;
serverless runtime;
batch execution;
stream processing runtime;
query engines;
distributed processing clusters;
accelerator-based compute.

Compute selection SHOULD be driven by workload characteristics such as:

latency;
throughput;
cost;
resilience;
security;
regulatory constraints;
scalability.

Compute technology does not determine whether a capability is a Data Transformer, Data Distributor, or Data Product.

8.5 Storage

Storage provides persistence for data and supporting metadata.

Storage MAY include:

relational stores;
object stores;
document stores;
graph stores;
key-value stores;
event logs;
analytical stores;
feature stores;
caches;
archival stores.

Storage type does not determine:

authority;
ownership;
product status;
semantic meaning.

A lakehouse is not automatically an Authoritative Source.

A database is not automatically a System of Record.

8.6 Network

Network capabilities provide connectivity between systems, platforms, environments, domains, and consumers.

Network architecture MAY support:

private connectivity;
public connectivity;
segmentation;
routing;
firewalling;
service mesh;
cross-region connectivity;
cross-cloud connectivity.

Network architecture SHOULD reflect data sensitivity, residency, availability, and trust-boundary requirements.

8.7 Identity and Access Management

IAM provides technical mechanisms for:

identity;
authentication;
authorization;
role assignment;
service identity;
credential management.

IAM MAY support entitlement enforcement but does not itself define the business semantics of entitlement.

The Consumption & Access Plane determines governed access intent.

IAM implements technical access enforcement.

8.8 Messaging and Event Infrastructure

Messaging infrastructure MAY support:

queues;
event streams;
pub/sub;
event buses;
durable logs;
message routing.

Messaging technology MAY realize Data Transport / Relay or Data Distributor capabilities.

A messaging product called a “broker” MUST NOT automatically be modeled as a GEDRM Data Broker.

8.9 API Infrastructure

API infrastructure MAY support:

API gateways;
service endpoints;
routing;
throttling;
authentication;
authorization;
version routing;
rate limiting;
observability.

An API gateway MAY support Data Provider or Data Publisher behavior but is not automatically either role.

The semantic role depends on how it participates in the governed interaction.

8.10 Orchestration

Orchestration coordinates multi-step runtime behavior.

It MAY include:

workflow engines;
schedulers;
dependency execution;
retries;
state management;
event-driven coordination.

Orchestration MAY support:

processing;
control execution;
product publication;
lifecycle transitions;
remediation.

Orchestration logic SHOULD remain traceable to architectural responsibilities.

8.11 CI/CD and Deployment Automation

CI/CD MAY support:

code validation;
schema validation;
contract validation;
policy validation;
automated testing;
artifact publication;
deployment;
rollback;
promotion between environments.

GEDRA favors automation where it improves consistency and governance, but automation does not change semantic responsibility.

For example:

CI/CD validates a Data Contract

does not make CI/CD the owner of the Data Contract.

8.12 Configuration Management

Configuration SHOULD be versioned and governed where it affects data behavior.

This MAY include:

runtime configuration;
routing;
access rules;
product configuration;
control thresholds;
environment settings;
retention configuration.

Configuration SHOULD be reproducible where material.

8.13 Secrets and Key Management

Technical foundations SHOULD provide secure management of:

credentials;
encryption keys;
API secrets;
certificates;
service identities.

Secrets SHOULD NOT be embedded in data products, contracts, code repositories, or uncontrolled configuration.

8.14 Runtime Hosting

Runtime hosting MAY include:

on-premises infrastructure;
private cloud;
public cloud;
hybrid cloud;
edge;
managed service;
SaaS.

GEDRA remains hosting-neutral.

Hosting choice SHOULD reflect:

security;
residency;
latency;
resilience;
cost;
operating model;
regulatory obligations.

8.15 Container and Platform Runtime

Container orchestration or platform runtimes MAY host:

Data Transformers;
Data Providers;
Data Publishers;
Data Distributors;
Data Brokers;
metadata services;
governance services;
control execution services.

The runtime is an implementation host, not the GEDRA role itself.

8.16 Backup and Disaster Recovery

Backup and disaster recovery capabilities SHOULD support:

data recovery;
service recovery;
metadata recovery;
product restoration;
evidence retention where required.

DR design SHOULD account for:

recovery point objective;
recovery time objective;
authority consistency;
data freshness;
cross-region constraints;
retention;
legal or regulatory requirements.

A backup copy MUST NOT become authoritative merely because it is used during recovery.

8.17 Resilience

Resilience MAY include:

redundancy;
failover;
multi-region design;
replay;
recovery;
workload isolation;
graceful degradation.

Resilience SHOULD be proportionate to product, consumer, and regulatory obligations.

Not every Data Asset requires the same resilience level.

8.18 Observability Tooling

Technology MAY provide:

metrics;
logs;
traces;
dashboards;
alerting;
lineage events;
quality telemetry;
cost telemetry.

These tools support the Value, Observability & Feedback Plane.

They do not automatically define:

Data Controls;
Control Evidence;
Product Health semantics;
Value.

Those meanings are governed elsewhere in GEDRA.

8.19 Policy Enforcement Runtime

Technology MAY implement runtime enforcement of:

access policy;
residency policy;
masking policy;
publication rules;
distribution rules;
retention rules.

The runtime mechanism SHOULD remain traceable to:

Data Policy;
Policy as Code;
applicable scope;
version;
control where relevant.

The policy engine does not become the policy authority by implementation alone.

8.20 Metadata Infrastructure

Metadata infrastructure MAY support:

catalog;
registry;
lineage;
glossary;
ontology;
schema registry;
product registry;
control registry;
policy registry.

A metadata platform MAY host multiple GEDRA responsibilities.

Its existence does not collapse their semantics into one concept.

8.21 AI Orchestration

AI orchestration MAY support:

model invocation;
routing;
prompt/runtime coordination;
model registry interaction;
feature retrieval;
vector retrieval;
evaluation;
monitoring.

AI orchestration is an enabling capability.

It MUST NOT bypass existing:

data classification;
privacy;
policy;
access;
lineage;
authority;
control requirements.

AI processing remains subject to the same governed data architecture principles.

8.22 Environment Management

A mature foundation SHOULD distinguish environments such as:

development
test
pre-production
production
disaster recovery

where appropriate.

Environment transitions SHOULD preserve relevant:

configuration;
policy;
contracts;
schema;
product version;
control version;
evidence requirements.

8.23 Utility Services

GEDRA allows shared utility services where reusable capability is justified.

Examples MAY include:

identity;
secrets;
metadata;
policy evaluation;
lineage;
observability;
notifications;
scheduling;
schema validation.

A shared utility SHOULD have a clear service boundary and accountability.

Shared does not mean globally mandatory for every workload.

8.24 Shared vs Embedded Capability

A GEDRA-aligned implementation MAY realize a capability as:

centralized shared service;
federated shared service;
domain-local service;
embedded product-local capability.

For example:

Policy evaluation

may be centralized for authoring and product-local for runtime enforcement.

GEDRA does not require one deployment pattern universally.

8.25 Technology Selection Principles

Technology SHOULD be selected based on architectural obligations.

Relevant criteria MAY include:

semantic compatibility;
interoperability;
scale;
latency;
resilience;
security;
residency;
lifecycle;
observability;
cost;
portability;
operability;
supportability;
automation;
vendor risk.

Technology SHOULD NOT be selected merely because it is strategically fashionable.

8.26 Portability and Avoidance of Semantic Lock-In

Technology choices SHOULD avoid embedding enterprise semantics so deeply into proprietary implementation constructs that they cannot be represented independently.

For example:

Enterprise concept
    SHOULD NOT exist only as
VendorProduct.Table.Column

where that would prevent semantic portability.

GEDRM/GEDRA semantics SHOULD remain portable across technology evolution.

8.27 Interoperability

The foundation SHOULD support interoperability between:

domains;
platforms;
clouds;
products;
consumer classes;
external parties.

Interoperability MAY rely on:

open standards;
stable interfaces;
explicit contracts;
semantic mappings;
portable metadata;
versioning.

Interoperability is not achieved by transport connectivity alone.

8.28 Technology Lifecycle

Technical capabilities SHOULD have explicit lifecycle management where their change may affect data architecture.

Lifecycle MAY include:

adopt
standardize
operate
upgrade
deprecate
retire

Technology retirement SHOULD consider impact on:

products;
contracts;
consumers;
lineage;
controls;
evidence;
historical reproducibility.

8.29 Technology Change and Architectural Stability

GEDRA SHOULD allow technology to change without forcing semantic redefinition.

For example:

Data Product
   before: implemented on Platform A
   after:  implemented on Platform B

may remain the same Data Product if its governed identity, promise, semantics, and obligations remain stable.

This separation is a core purpose of the foundation boundary.

8.30 Multi-Cloud and Hybrid Architecture

GEDRA supports:

single-cloud;
multi-cloud;
hybrid;
on-premises;
mixed hosting.

Cloud topology SHOULD NOT redefine data roles.

For example:

Authoritative Source in Cloud A
Data Distributor in Cloud B
Consumer on-premises

is valid if governance, security, residency, latency, and operational obligations are satisfied.

8.31 Technology and Authority

Technology placement MUST NOT be used as evidence of authority.

Examples of invalid assumptions:

"it is in the central warehouse, therefore authoritative"
"it is in MDM, therefore authoritative"
"it is on blockchain, therefore authoritative"
"it is in the enterprise lake, therefore authoritative"

Authority remains a governed semantic role.

8.32 Technology and Productization

Technology exposure MUST NOT be used as proof of productization.

Examples:

API exists
    !=
Data Product exists

Dataset is in marketplace
    !=
Data Product exists

Table is discoverable
    !=
Data Product exists

Productization requires the obligations defined in GEDRM and GEDRA.

8.33 Technology and Governance

Technology MAY automate governance.

It MUST NOT replace governance semantics.

Examples:

Policy Engine
    !=
Data Policy

DQ Tool
    !=
Data Quality Rule semantics

Dashboard
    !=
Data Control

Catalog
    !=
Data Owner

8.34 Security and Trust Boundaries

The foundation SHOULD make trust boundaries explicit where relevant.

Examples:

domain boundary;
network boundary;
cloud boundary;
tenant boundary;
jurisdiction boundary;
organization boundary;
external-party boundary.

Crossing a trust boundary SHOULD trigger appropriate:

authentication;
authorization;
encryption;
policy;
logging;
control;
evidence.

8.35 Capacity and Scalability

Capacity SHOULD reflect expected:

volume;
velocity;
concurrency;
retention;
consumer demand;
growth;
failure scenarios.

Capacity planning MAY use signals from the Value, Observability & Feedback Plane.

8.36 Performance

Performance requirements MAY include:

latency;
throughput;
query response;
publication delay;
processing duration;
recovery time.

Performance SHOULD align to actual consumer and product obligations.

8.37 Cost

Technology architecture SHOULD expose sufficient cost information to support economic accountability.

Cost SHOULD be attributable where practical to:

platform;
product;
domain;
consumer;
workload.

Technology cost does not determine product value by itself.

8.38 Operational Ownership

Technical capabilities SHOULD have clear operational ownership.

Operational ownership MAY include:

uptime;
patching;
deployment;
incident response;
capacity;
upgrade;
support.

Operational ownership does not imply Data Ownership or Product Ownership.

8.39 Service Management

Foundation capabilities MAY use service-management practices such as:

incident management;
problem management;
change management;
capacity management;
availability management.

GEDRA does not prescribe a specific service-management framework.

8.40 Runtime Dependency Management

Material runtime dependencies SHOULD be discoverable.

Examples:

Data Product
    depends on:
      storage
      compute
      messaging
      metadata
      IAM
      policy runtime

Dependency visibility supports:

impact analysis;
resilience;
change management;
cost analysis.

8.41 Recovery Semantics

Recovery SHOULD preserve semantic and governance correctness.

After recovery, the architecture SHOULD be able to determine:

which data version is restored;
whether authority remains valid;
whether product version is unchanged;
whether contracts remain satisfied;
whether controls need re-execution;
whether consumers need notification.

8.42 Infrastructure as Code

Infrastructure as Code MAY improve reproducibility.

Where used, it SHOULD support:

versioning;
review;
traceability;
controlled deployment;
rollback.

Infrastructure as Code is not Policy as Code.

The two MUST remain distinct.

8.43 Technology / Utility Foundation Interaction with GEDRA Planes

Semantic Plane

Supports:

ontology repositories;
glossary tooling;
metadata stores;
semantic APIs;
graph stores.

Technology does not define meaning.

Authority Plane

Supports:

source registration;
authoritative-source metadata;
state persistence;
lineage;
replication.

Technology does not establish authority by itself.

Processing, Provision & Movement

Supports:

compute;
messaging;
API infrastructure;
orchestration;
streaming;
transfer.

Technology implements operational roles.

Data Platform & Product

Supports:

storage;
product runtime;
registry;
catalog;
marketplace;
metadata;
quality;
lineage;
observability.

Technology enables productization.

Consumption & Access

Supports:

IAM;
gateways;
query engines;
federation;
entitlement runtime;
interfaces.

Technology enforces access.

Value, Observability & Feedback

Supports:

telemetry;
dashboards;
cost systems;
alerting;
analytics.

Technology emits signals.

8.44 Interaction with Cross-Cutting Governance & Control

The foundation SHOULD provide technical support for:

policy enforcement;
access control;
encryption;
audit;
evidence retention;
control execution;
exception workflows;
lifecycle automation.

The governance model defines why these exist and what they mean.

The foundation defines how they may be implemented.

8.45 Architectural Boundaries

The Technology / Utility Foundation does not define:

business semantics;
data authority;
product identity;
Data Ownership;
Source of Authority;
consumer purpose;
Data Policy meaning;
control semantics.

It provides enabling capability.

8.46 Anti-Patterns

The following are Technology / Utility Foundation anti-patterns.

Technology-First Architecture

Starting with vendor products and inferring the architecture afterward.

Product Name Equals Role

Assuming a product's marketing label determines its GEDRA role.

Platform Equals Data Architecture

Treating the platform diagram as the complete enterprise data architecture.

Central Platform Equals Authority

Assuming centralized storage is authoritative by default.

Shared Service Everywhere

Forcing every domain or product through one shared service regardless of need.

Tool Equals Governance

Assuming a catalog, policy engine, DQ tool, or observability platform is equivalent to the governance model.

Infrastructure as Code Equals Policy as Code

Conflating deployment automation with executable governance policy.

Backup Equals Authoritative Copy

Treating restored or replicated backup data as authoritative without validation.

Technology Lock-In of Semantics

Encoding enterprise meaning only in proprietary schemas or platform constructs.

AI Exception to Governance

Allowing AI-related runtime or model tooling to bypass ordinary data governance.

8.47 Minimum GEDRA 0.1 Conformance Expectations

An architecture claiming alignment with the Technology / Utility Foundation SHOULD demonstrate that:

data architecture roles are distinguishable from implementation technologies;
platform/runtime services are treated as enabling capabilities;
storage technology does not imply authority;
messaging products are not automatically treated as GEDRM Data Brokers;
API infrastructure does not automatically define product or publisher semantics;
IAM implements access controls without replacing entitlement semantics;
observability tools do not automatically define controls or evidence;
policy engines remain traceable to authoritative Data Policy;
operational ownership is distinct from Data Ownership and Product Ownership;
technology change can occur without unnecessary semantic redefinition;
infrastructure choices can be impact-assessed across products, consumers, controls, and evidence;
AI runtime capabilities remain subject to ordinary data governance obligations;
trust boundaries and resilience obligations can be represented where material;
technology does not become a substitute for GEDRM/GEDRA semantics.

8.48 Illustrative Technology / Utility Foundation View

                    TECHNOLOGY / UTILITY FOUNDATION

 Compute      Storage      Network       IAM
 Messaging    APIs         Orchestration CI/CD
 Secrets      Runtime      Backup / DR   Observability
 Metadata     Policy Runtime             AI Orchestration

                          |
                          v

     Enables all GEDRA architectural planes and governance concerns

                          |
        +-----------------+------------------+
        |                 |                  |
        v                 v                  v
   Semantics          Data Roles        Governance
   remain governed    remain explicit   remains semantic

 Technology enables implementation.
 Technology does not define meaning, authority, ownership, or product status.

9. Reusable Architecture Patterns

9.1 Purpose

GEDRA reusable Architecture Patterns define repeatable arrangements of GEDRM concepts, GEDRA planes, governance responsibilities, and interactions that address recurring enterprise data architecture problems.

A pattern is not a mandatory implementation blueprint. It describes a recurring architectural problem, identifies semantic and architectural roles, defines responsibility boundaries, shows a preferred logical arrangement, highlights governance obligations, and identifies common anti-patterns.

Patterns MAY be composed.

GEDRA 0.1 defines the following core reusable patterns:

Scoped Authority Pattern;
Authoritative Sourcing Pattern;
Governed Derivation Pattern;
Governed Distribution Pattern;
Data Productization Pattern;
Policy-to-Control-to-Evidence Pattern;
Privacy Processing-Role Pattern;
Consumer Access Pattern;
Feedback and Product Evolution Pattern;
Governed Copy / Cache Pattern.

These patterns are technology-neutral.

9.2 Scoped Authority Pattern

9.2.1 Problem

Enterprises often describe an application, database, or platform as "the source of truth" without defining what it is authoritative for, what kind of authority is intended, who designated it, or how that authority changes over time.

9.2.2 Intent

Make authority explicit, scoped, governed, and traceable.

9.2.3 Logical Pattern

Source of Authority
      |
      | designates
      v
Authoritative Source
      |
      | authoritative for
      v
Governed Data Scope

System of Record
      |
      | records authoritative state for
      v
Governed State Scope

9.2.4 Rules

System of Record != Authoritative Source
Authoritative Source != Source of Authority

Authority SHOULD be scoped by concept, entity, attribute, lifecycle stage, jurisdiction, business capability, purpose, product, contract, or time period.

9.2.5 Anti-Patterns

global "source of truth" statements without scope;
authority inferred from technology;
authority inferred from popularity;
authority inferred from mastering;
authority changes without downstream impact analysis.

9.2.6 Conformance

A conforming use SHOULD demonstrate explicit scope, state-vs-sourcing authority, designation authority, currentness, and downstream discoverability.

9.3 Authoritative Sourcing Pattern

9.3.1 Problem

Consumers frequently source data from convenient copies rather than governed sources, creating stale data, conflicting representations, unmanaged lineage, and duplicated reconciliation.

9.3.2 Intent

Ensure that consumers obtain defined data from an explicitly governed Authoritative Source.

9.3.3 Logical Pattern

System(s) of Record
        |
        | governed projection / extraction / assembly
        v
Authoritative Source
        |
        | approved sourcing relationship
        v
Consumer / Data Product / Processing Capability

The Authoritative Source MAY be the SoR directly, a governed projection, mastered representation, federated view, assembled source, or derived source.

Where it is not the SoR, lineage SHOULD remain explicit.

9.3.4 Conformance

A conforming use SHOULD show explicit Authoritative Source, source-to-consumer lineage, scope, copy/staleness status where relevant, and change propagation.

9.4 Governed Derivation Pattern

9.4.1 Problem

Derived data is often treated as if it retains the same meaning, authority, and governance status as its inputs.

9.4.2 Intent

Make derivation explicit, traceable, semantically governed, and authority-safe.

9.4.3 Logical Pattern

Input Data
    |
    | isInputTo
    v
Derivation Activity
    |
    | produces
    v
Derived Data

A material derivation SHOULD identify inputs, versions/snapshots where required, calculation or transformation logic, output semantics, time, ownership, quality rules, authority status, and downstream dependencies.

9.4.4 Rules

Derived Data != Authoritative Source

unless explicitly designated.

AI feature generation, embeddings, predictions, classifications, and model outputs MAY use this pattern and remain subject to lineage, privacy, authority, quality, policy, and reproducibility obligations.

9.4.5 Conformance

A conforming use SHOULD support explicit derivation activity, source lineage, semantic definition, authority status, reproducibility where required, and change impact analysis.

9.5 Governed Distribution Pattern

9.5.1 Problem

Data movement is often modeled as a technical transport problem, causing publication, delivery, permission, redistribution, contract, and authority responsibilities to be lost.

9.5.2 Intent

Separate publication, provision, transport, distribution, and brokerage while preserving governance.

9.5.3 Logical Pattern

Authoritative Source / Data Product
            |
            v
       Data Publisher
            |
            v
        Data Provider
            |
            v
      Data Distributor
            |
            v
     Permitted Consumer

Optional mediation:

Provider / Publisher
       |
       v
   Data Broker
       |
       v
    Consumer

Transport / Relay MAY carry data between these roles.

9.5.4 Responsibility Separation

Publisher = intentional release
Provider = makes available
Distributor = delivers
Transport / Relay = carries
Broker = mediates

9.5.5 HDIP Specialization

Data Distributor
      |
      +-- HDIP: Authorized Data Distributor (ADD)

ADD does not become authoritative merely because it is authorized to distribute.

9.5.6 Conformance

A conforming use SHOULD show the semantic role of each participant, publication context where relevant, permitted recipients, authority status, contract/policy obligations, and delivery observability.

9.6 Data Productization Pattern

9.6.1 Problem

Organizations often label datasets, APIs, reports, or tables as Data Products without accepting product obligations.

9.6.2 Intent

Provide a repeatable pattern for intentionally promoting a governed Data Asset into a Data Product.

9.6.3 Logical Pattern

Data Object
    |
    | governed / valuable
    v
Data Asset
    |
    | intentional productization decision
    v
Data Product

9.6.4 Product Obligations

A productized asset SHOULD establish:

Stable Identity
Accountable Product Owner
Product Promise
Semantic Definition
Version
Lifecycle
Output Port(s)
Data Contract where required
Policy / Access
Quality Expectations
Lineage
Discoverability
Observability
Support / Change Model

9.6.5 Boundary Rules

Data Asset != Data Product
Catalog Entry != Data Product
API != Data Product
Marketplace Listing != Data Product

Marketplace participation is optional.

9.6.6 Conformance

A conforming use SHOULD demonstrate intentional promotion, accountable ownership, Product Promise, stable identity, lifecycle/versioning, governed interfaces, discoverability, consumer-facing obligations, observability, and distinction from platform capability.

9.7 Policy-to-Control-to-Evidence Pattern

9.7.1 Problem

Requirements, policies, rules, metrics, controls, and evidence are frequently conflated, creating apparent governance without demonstrable assurance.

9.7.2 Intent

Provide a reusable path from governed expectation to executable assurance and evidence.

9.7.3 Logical Pattern

Requirement / Regulation / Obligation
                |
                v
           Data Policy
                |
        applicability resolution
                |
        +-------+-------+
        |               |
        v               v
   Policy as Code   Data Contract / Rule
        |               |
        +-------+-------+
                |
                v
           Data Control
                |
                v
        Control Execution
                |
                v
        Control Evidence

Not every branch is mandatory.

9.7.4 Semantic Locks

Policy != Policy as Code
Policy != Control
Rule != Control
Metric != Control
Log != Control Evidence

9.7.5 Product-Local Governance

A Data Product version MAY bind a resolved governance bundle containing policy, contract, rule, and control versions to support reproducibility.

9.7.6 Conformance

A conforming use SHOULD show governed expectation, applicability, control ownership, execution semantics, evidence linkage, version traceability, and exception/remediation path where required.

9.8 Privacy Processing-Role Pattern

9.8.1 Problem

Technical processing roles are often confused with legal/privacy roles.

9.8.2 Intent

Keep operational data-flow roles distinct from legal/privacy accountability.

9.8.3 Logical Pattern

Data Controller
      |
      | determines purpose / essential means
      v
Processing Activity
      |
      | processes
      v
Personal Data

Operational role:
  Data Transformer

Legal/privacy role:
  Data Processor
      |
      | processes on behalf of
      v
Data Controller

9.8.4 Core Rule

Data Transformer != Data Processor

One capability MAY perform both roles in context.

9.8.5 Conformance

A conforming use SHOULD demonstrate distinct legal and operational roles, explicit Processing Activity context, identifiable Personal Data scope, Controller responsibility where applicable, and Processor-on-behalf-of relationships where applicable.

9.9 Consumer Access Pattern

9.9.1 Problem

Access is frequently reduced to IAM or API permission while consumer purpose, suitability, entitlement, and downstream obligations remain implicit.

9.9.2 Intent

Provide a governed discovery-to-consumption flow.

9.9.3 Logical Pattern

Discovery
    |
    v
Suitability Assessment
    |
    v
Access Request
    |
    v
Entitlement & Policy Evaluation
    |
    v
Provisioned Access
    |
    v
Consumption
    |
    v
Feedback / Usage

9.9.4 Rules

Discovery != Entitlement
Access != Understanding
Authorization != Entitlement semantics
Fit for one purpose != Fit for every purpose

9.9.5 Conformance

A conforming use SHOULD demonstrate intended consumer, intended use, discovery, suitability information, governed entitlement, lifecycle/revocation, downstream obligations, and feedback path.

9.10 Feedback and Product Evolution Pattern

9.10.1 Problem

Data platforms and products often collect telemetry without turning it into product or architecture decisions.

9.10.2 Intent

Create an explicit feedback loop from consumption and operation into evolution.

9.10.3 Logical Pattern

Consumption
    |
    v
Usage / Operational Signals
    |
    v
Observability
    |
    +--> Quality
    +--> Cost
    +--> Contract Performance
    +--> Consumer Feedback
    +--> Value
    |
    v
Assessment
    |
    v
Decision
    |
    +--> Improve
    +--> Scale
    +--> Optimize
    +--> Consolidate
    +--> Deprecate
    +--> Retire

9.10.4 Rules

Usage != Value
Cost != Value

Product health SHOULD remain multidimensional rather than being collapsed into one status.

9.10.5 Conformance

A conforming use SHOULD demonstrate observable usage/health, value assessment, consumer feedback, an accountable decision path, downstream impact analysis, and lifecycle action.

9.11 Governed Copy / Cache Pattern

9.11.1 Problem

Copies, caches, replicas, and materialized views often proliferate for legitimate reasons while losing source lineage, freshness semantics, authority status, retention, ownership, and consumer purpose.

9.11.2 Intent

Allow justified non-owning copies without losing governance or authority context.

9.11.3 Logical Pattern

Authoritative Source
        |
        | replicated / cached / materialized
        v
   Non-Owning Copy
        |
        +-- source lineage
        +-- freshness
        +-- retention
        +-- purpose
        +-- authority = non-authoritative unless designated
        |
        v
     Consumer

A copy MAY be justified for performance, locality, resilience, historical reproducibility, workload isolation, analytics, regulatory retention, or availability.

9.11.4 Rules

Copy / Cache / Replica != Authoritative Source
Persistent Copy != Data Product

unless separately designated or intentionally productized.

9.11.5 Conformance

A conforming use SHOULD show reason for copy, authoritative source, synchronization/freshness model, retention/lifecycle, authority status, and consumer scope.

9.12 Pattern Composition

GEDRA patterns are designed to compose.

For example:

Scoped Authority
      |
      v
Authoritative Sourcing
      |
      v
Governed Derivation
      |
      v
Data Productization
      |
      v
Governed Distribution
      |
      v
Consumer Access
      |
      v
Feedback & Product Evolution

Cross-cutting:
  Policy-to-Control-to-Evidence
  Privacy Processing-Role

Optional:
  Governed Copy / Cache

This composition is logical rather than a mandatory runtime sequence.

9.13 Pattern Selection Guidance

Architects SHOULD select patterns based on the problem being solved:

use Scoped Authority when authority is ambiguous or distributed;
use Authoritative Sourcing when consumers require approved sourcing;
use Governed Derivation when calculations, transformations, inference, mastering, or aggregation create materially new data;
use Governed Distribution when publication, delivery, entitlement, or mediation responsibilities need to be explicit;
use Data Productization when a governed asset is intentionally promoted to a consumer-facing product;
use Policy-to-Control-to-Evidence when governed obligations require operational assurance;
use Privacy Processing-Role when Personal Data processing requires explicit legal-role modeling;
use Consumer Access when discovery, suitability, entitlement, and purpose must be governed;
use Feedback and Product Evolution when operational and consumer signals should drive lifecycle or architecture change;
use Governed Copy / Cache when non-owning persistence is justified.

9.14 Pattern Specialization

Enterprise or domain profiles MAY specialize GEDRA patterns by adding stricter controls, domain-specific roles, named-capability mappings, mandatory metadata, tighter cardinalities, lifecycle states, or evidence requirements.

A specialization MUST NOT redefine GEDRM or GEDRA semantics incompatibly.

9.15 Pattern Conformance

An implementation does not need to use every GEDRA pattern.

Where an architecture claims use of a specific GEDRA pattern, it SHOULD preserve:

semantic role distinctions;
stated architectural intent;
authority boundaries;
governance obligations;
product boundaries;
relevant conformance expectations.

Equivalent physical implementation is allowed.

Semantic incompatibility is not.

9.16 Pattern Anti-Pattern Principle

GEDRA anti-patterns are not universal prohibitions on technologies or implementation techniques.

They identify situations in which architectural meaning becomes ambiguous, responsibilities collapse, or governance obligations are hidden.

The same technology may participate in a conforming or non-conforming architecture depending on how its role is governed and represented.

9.17 Illustrative Pattern Map

                     GEDRA REUSABLE PATTERN MAP

              +------------------------+
              |   Scoped Authority     |
              +-----------+------------+
                          |
                          v
              +------------------------+
              | Authoritative Sourcing |
              +-----------+------------+
                          |
                          v
              +------------------------+
              |  Governed Derivation   |
              +-----------+------------+
                          |
                          v
              +------------------------+
              |   Data Productization  |
              +-----------+------------+
                          |
                          v
              +------------------------+
              | Governed Distribution  |
              +-----------+------------+
                          |
                          v
              +------------------------+
              |    Consumer Access     |
              +-----------+------------+
                          |
                          v
              +------------------------+
              | Feedback & Evolution   |
              +------------------------+

Cross-cutting:
  Policy -> Control -> Execution -> Evidence
  Controller / Processor / Processing Activity / Personal Data

Optional:
  Authoritative Source -> Governed Copy / Cache -> Consumer

The pattern map is a reasoning aid. GEDRA remains graph-shaped and does not require all patterns to execute in this order.

10. Architecture Views

10.1 Purpose

GEDRA Architecture Views provide stakeholder-oriented projections of the reference architecture.

A view does not create new semantics. It selects and arranges existing GEDRM concepts, GEDRA planes, cross-cutting governance concerns, and reusable patterns so that a particular architectural question can be understood clearly.

The purpose of the view model is to avoid forcing every stakeholder to consume one overloaded enterprise diagram.

GEDRA 0.1 defines the following core views:

Overview / Plane View;
Semantic View;
Authority View;
Processing, Provision & Movement View;
Data Platform & Product View;
Consumption & Access View;
Governance & Assurance View;
Privacy View;
Lineage & Provenance View;
Lifecycle & Change View;
Value, Observability & Feedback View;
HDIP Specialization View.

An enterprise or domain architecture MAY define additional views.

10.2 View Principles

A GEDRA view SHOULD:

state its concern and intended audience;
use GEDRM terminology consistently;
identify the GEDRA planes represented;
avoid implying that logical planes are separate applications;
show scope where authority, ownership, policy, or control is material;
distinguish logical role from physical implementation;
show only relationships relevant to the view;
remain compatible with the underlying GEDRA model.

Different views MAY show the same capability in different contexts.

For example, a platform service may appear as a technical implementation in the Technology / Utility Foundation, as a Data Distributor in a movement view, or as a policy-enforcement point in a governance view. This reflects multiple architectural concerns rather than incompatible identities.

10.3 Overview / Plane View

10.3.1 Purpose

The Overview / Plane View provides the highest-level representation of GEDRA.

It is intended for enterprise architects, data architects, business architects, technology leaders, governance leaders, programme architects, and senior stakeholders.

It answers:

What are the major architectural responsibility areas in enterprise data architecture, and how do they relate?

10.3.2 Logical View

+---------------------------------------------------------------+
|          Semantic & Enterprise Ontology Plane                 |
| meaning | concepts | relationships | classifications          |
+---------------------------------------------------------------+
                              |
                              v
+---------------------------------------------------------------+
|                     Authority Plane                           |
| origin | producer | SoR | Authoritative Source | authority    |
+---------------------------------------------------------------+
                              |
                              v
+---------------------------------------------------------------+
|          Processing, Provision & Movement Plane               |
| transform | transport | provide | publish | distribute | broker|
+---------------------------------------------------------------+
                              |
                              v
+---------------------------------------------------------------+
|              Data Platform & Product Plane                    |
| assets | products | metadata | lineage | quality | lifecycle  |
+---------------------------------------------------------------+
                              |
                              v
+---------------------------------------------------------------+
|               Consumption & Access Plane                      |
| discovery | suitability | entitlement | access | consumers    |
+---------------------------------------------------------------+
                              |
                              v
+---------------------------------------------------------------+
|          Value, Observability & Feedback Plane                |
| usage | cost | value | health | feedback | evolution          |
+---------------------------------------------------------------+

Cross-cutting across all planes:
  Governance & Control

Enabling all planes:
  Technology / Utility Foundation

10.3.3 Interpretation

The vertical arrangement is explanatory only.

GEDRA remains graph-shaped. Real implementations MAY branch, converge, loop, bypass particular planes, or combine multiple plane responsibilities in one capability.

10.3.4 Conformance

The overview view SHOULD preserve all six planes plus the cross-cutting Governance & Control Model and Technology / Utility Foundation.

10.4 Semantic View

10.4.1 Purpose

The Semantic View explains governed business meaning independently of physical representation.

It is intended for data architects, business architects, data modelers, stewards, product owners, analysts, and schema designers.

It answers:

What does the data mean?

10.4.2 Logical View

Enterprise / Domain Concepts
        |
        +-- Entity
        +-- Attribute / Property
        +-- Relationship
        +-- Role
        +-- Taxonomy
        +-- Controlled Vocabulary
        |
        v
Governed Semantic Meaning
        |
        +--> Physical Schema A
        +--> Physical Schema B
        +--> Data Product Schema
        +--> External Standard Mapping

10.4.3 Required Distinctions

Canonical Meaning != Canonical Physical Schema
Entity != Role
Business/Semantic Classification != Provenance Classification
Semantic Mapping != Exact Equivalence by default

10.5 Authority View

10.5.1 Purpose

The Authority View explains state authority, sourcing authority, and designation authority.

It answers:

Where is authoritative state maintained, where should data be sourced, and who established that authority?

10.5.2 Logical View

Source of Authority
      |
      | designates
      v
Authoritative Source
      |
      | authoritative for
      v
Governed Scope

System of Record
      |
      | records authoritative state for
      v
Governed State Scope

Optional origin context:

Data Originator
      |
      v
Data Producer
      |
      v
System of Record / Flow

10.5.3 Required Distinctions

Data Originator != Data Producer
System of Record != Authoritative Source
Authoritative Source != Source of Authority
Authorized != Authoritative

The view SHOULD make authority scope visible by concept, attribute, lifecycle stage, jurisdiction, purpose, time, or business capability.

10.6 Processing, Provision & Movement View

10.6.1 Purpose

This view explains how data is transformed, transported, exposed, published, distributed, or mediated.

It answers:

Who changes, carries, exposes, publishes, delivers, or mediates the data?

10.6.2 Logical View

Source / Producer
      |
      v
Data Transformer
      |
      v
Data Publisher
      |
      v
Data Provider
      |
      v
Data Distributor
      |
      v
Recipient / Consumer

Optional:
  Data Broker mediates provider-consumer interaction

Transport / Relay may carry data between any of these roles.

10.6.3 Required Distinctions

Transformer != Data Processor
Transport != Distributor
Provider != Publisher
Distributor != Authoritative Source
Technical message broker != GEDRM Data Broker

10.7 Data Platform & Product View

10.7.1 Purpose

The Data Platform & Product View explains the relationship between shared data capabilities, governed Data Assets, intentional Data Products, and product lifecycle.

It answers:

What is the governed asset, what has been intentionally productized, and which platform capabilities enable it?

10.7.2 Logical View

Platform Capabilities
  storage
  processing
  metadata
  lineage
  quality
  security
  governance
  discovery
  observability
  productization
         |
         v
      Data Asset
         |
         | intentional productization
         v
      Data Product
         |
         +-- identity
         +-- owner
         +-- Product Promise
         +-- version
         +-- lifecycle
         +-- contract
         +-- output ports
         +-- lineage
         +-- policy / controls
         +-- observability

10.7.3 Required Distinctions

Data Object != Data Asset
Data Asset != Data Product
Platform != Data Product
Output Port != Data Product
Catalog Entry != Data Product
Marketplace Listing != Data Product

10.8 Consumption & Access View

10.8.1 Purpose

The Consumption & Access View explains how data is discovered, assessed, entitled, accessed, and used.

It answers:

Who is consuming, for what purpose, and under what governed access conditions?

10.8.2 Logical View

Discovery
    |
    v
Suitability Assessment
    |
    v
Access Request
    |
    v
Entitlement & Policy Evaluation
    |
    v
Provisioned Access
    |
    v
Data Recipient / Data Consumer
    |
    v
Feedback

10.8.3 Required Distinctions

Recipient != Consumer
Discovery != Entitlement
Authentication != Authorization
Authorization != Entitlement semantics
Access != unrestricted reuse

The view MAY distinguish operational, regulatory, risk, finance, analytics, AI/ML, external, downstream Data Product, and audit/assurance consumers.

10.9 Governance & Assurance View

10.9.1 Purpose

The Governance & Assurance View explains how obligations become operationally governed and evidenced.

It answers:

What is required, how is it governed, how is it assured, and what evidence proves operation?

10.9.2 Logical View

Requirement / Regulation / Obligation
                |
                v
            Data Policy
                |
        applicability resolution
                |
       +--------+---------+
       |                  |
       v                  v
Data Contract       Policy as Code / Rules
       |                  |
       +--------+---------+
                |
                v
           Data Control
                |
                v
        Control Execution
                |
                v
        Control Evidence
                |
                v
      Assurance / Remediation

10.9.3 Required Distinctions

Requirement != Control
Policy != Policy as Code
Policy != Control
Data Contract != Control
DQ Rule != Control
Metric != Control
Log != Control Evidence

The view MAY overlay controls across any GEDRA plane.

10.10 Privacy View

10.10.1 Purpose

The Privacy View explains privacy/legal role assignments in relation to Personal Data and Processing Activities.

It answers:

Who determines purpose and essential means, who processes on whose behalf, and which Personal Data is involved?

10.10.2 Logical View

Data Controller
      |
      | determines purpose / essential means
      v
Processing Activity
      |
      | processes
      v
Personal Data

Data Processor
      |
      | processes on behalf of
      v
Data Controller

Technical role:
  Data Transformer

10.10.3 Required Distinctions

Data Controller != Data Owner
Data Processor != Data Transformer
Data Processor != Data Custodian

A single organization MAY occupy multiple roles in different Processing Activities.

10.11 Lineage & Provenance View

10.11.1 Purpose

The Lineage & Provenance View explains where data came from, how it changed, which representations were involved, and what dependencies exist.

It answers:

Where did this data come from, what happened to it, and what depends on it?

10.11.2 Logical View

Data Originator
      |
      v
Data Producer
      |
      v
System of Record / Authoritative Source
      |
      v
Transformation / Derivation Activity
      |
      v
Data Asset / Data Product
      |
      v
Output Port / Distribution
      |
      v
Consumer / Downstream Product

The view MAY distinguish business, semantic, technical, transformation, authority, product-dependency, and control/evidence lineage.

Material regulated or evidential flows SHOULD be reproducible to the level required by their obligations.

10.12 Lifecycle & Change View

10.12.1 Purpose

The Lifecycle & Change View explains version, currentness, deprecation, retirement, effective dates, and downstream impact.

It answers:

What is current, what changed, when does the change apply, and what is affected?

10.12.2 Logical View

Current Governed State
        |
        | proposed change
        v
Impact Assessment
        |
        +--> semantics
        +--> authority
        +--> contracts
        +--> products
        +--> controls
        +--> consumers
        +--> lineage
        |
        v
Approved Change
        |
        v
New Version / Effective State
        |
        +--> previous version retained as required
        +--> migration / deprecation
        +--> downstream invalidation

Currentness SHOULD support version, effective-from, effective-to, superseded-by, deprecated, withdrawn, and review date where applicable.

10.13 Value, Observability & Feedback View

10.13.1 Purpose

The Value, Observability & Feedback View explains operational health, usage, cost, value, feedback, and evolution.

It answers:

Is the capability healthy, used, valuable, and economically sustainable, and what should change?

10.13.2 Logical View

Consumption
    |
    v
Usage / Operational Signals
    |
    +--> Quality
    +--> Freshness
    +--> Availability
    +--> Contract Performance
    +--> Cost
    +--> Consumer Feedback
    |
    v
Value / Health Assessment
    |
    v
Decision
    |
    +--> Improve
    +--> Optimize
    +--> Scale
    +--> Consolidate
    +--> Deprecate
    +--> Retire

10.13.3 Required Distinctions

Metric != Control
Observability Signal != Control Evidence
Usage != Value
Cost != Value

10.14 HDIP Specialization View

10.14.1 Purpose

The HDIP Specialization View demonstrates how a concrete strategic Data & AI architecture can specialize GEDRA without redefining generic GEDRM/GEDRA semantics.

It answers:

How do HDIP-specific architectural constructs map to GEDRA?

10.14.2 Core Mapping

GEDRA / GEDRM                     HDIP Specialization
---------------------------------------------------------------
Authoritative Source              Authorized Data Source (ADS)
Data Distributor                  Authorized Data Distributor (ADD)
Data Originator                   Authorized Data Originator (ADO), if adopted
Data Product                      HDIP Data Product
AI Product                        HDIP/AIPS AI Product specialization
Data Platform & Product Plane     HDIP platform/product capabilities
Governance & Control              HDIP governance/runtime policy model

10.14.3 Specialization Rule

HDIP MAY add authorization criteria, readiness gates, deployment requirements, registries, runtime policy resolution, product lifecycle, and platform implementation patterns.

HDIP MUST NOT redefine generic GEDRM concepts incompatibly.

The generic GEDRA diagrams SHOULD retain generic terminology. HDIP-specific views MAY show HDIP-specific names.

10.15 View Composition

GEDRA views MAY be composed.

For example, a regulatory reporting architecture may combine:

Semantic View
    +
Authority View
    +
Lineage & Provenance View
    +
Data Platform & Product View
    +
Governance & Assurance View
    +
Consumption & Access View

A privacy-sensitive Data Product may combine:

Data Platform & Product View
    +
Privacy View
    +
Consumption & Access View
    +
Governance & Assurance View

View composition SHOULD avoid duplicating or redefining concepts.

10.16 View Selection Guidance

Use the Overview / Plane View for executive and enterprise-level orientation.

Use the Semantic View when meaning, classification, or representation mapping is primary.

Use the Authority View for source-of-truth, System-of-Record, or authoritative-sourcing questions.

Use the Processing, Provision & Movement View for transformations, transport, publication, distribution, and mediation.

Use the Data Platform & Product View for Data Asset, Data Product, productization, and shared platform capability.

Use the Consumption & Access View for consumers, entitlement, discovery, suitability, and access.

Use the Governance & Assurance View for policy, contracts, controls, evidence, and exceptions.

Use the Privacy View where Personal Data and Controller/Processor roles matter.

Use the Lineage & Provenance View where origin, transformation, dependency, or reproducibility matters.

Use the Lifecycle & Change View where versioning, currentness, migration, and invalidation matter.

Use the Value, Observability & Feedback View for health, adoption, economics, and evolution.

Use the HDIP Specialization View when mapping GEDRA into HDIP.

10.17 View Conformance

An architecture MAY use different notation, modeling tools, or diagram styles.

A view claiming GEDRA alignment SHOULD preserve:

GEDRM semantic distinctions;
GEDRA plane responsibilities;
scoped authority;
governed ownership;
applicable product boundaries;
applicable governance/control semantics;
logical-vs-physical distinction.

A visually different view MAY still conform.

A semantically incompatible view does not.

10.18 Relationship to the Canonical GEDRA Overview / Plane View

The reconciled Generic Enterprise Data Architecture diagram is now the canonical GEDRA 0.1 Overview / Plane View.

It uses generic GEDRA terminology, including Data Originator, Data Producer, System of Record, Authoritative Source, Source of Authority, Data Transformer, Data Transport / Relay, Data Provider, Data Publisher, Data Distributor, and Data Broker.

HDIP-specific terms such as ADS and ADD are intentionally reserved for the HDIP Specialization View and profile.

The canonical overview preserves the Business Product vs Data Product distinction and treats the Technology / Utility Foundation as enabling rather than defining the data architecture.

Detailed concerns such as privacy-role relationships, control execution, and full lineage semantics belong in their dedicated GEDRA views rather than being forced into the overview.

10.19 Illustrative View Catalogue

GEDRA ARCHITECTURE VIEWS
|
+-- Overview / Plane View
+-- Semantic View
+-- Authority View
+-- Processing, Provision & Movement View
+-- Data Platform & Product View
+-- Consumption & Access View
+-- Governance & Assurance View
+-- Privacy View
+-- Lineage & Provenance View
+-- Lifecycle & Change View
+-- Value, Observability & Feedback View
+-- HDIP Specialization View

Together, these views allow GEDRA to remain one coherent reference architecture while presenting only the concerns relevant to each stakeholder or architectural decision.

11. Derivation & Conformance Guidance

11.1 Purpose

The Derivation & Conformance Guidance defines how GEDRA 0.1 is used to create concrete enterprise, domain, programme, and solution data architectures, and how those architectures may claim alignment with GEDRA without being forced into one physical implementation model.

Its purpose is to answer:

How is a concrete architecture derived from GEDRA?
Which parts of GEDRA are normative?
What may be specialized?
What may be omitted?
What must remain semantically compatible?
What does “GEDRA-aligned” mean?
How should architectural deviations and extensions be governed?
How can conformance be assessed without reducing GEDRA to a vendor or topology standard?

GEDRA is a reference architecture. It constrains architectural meaning and responsibility rather than prescribing identical implementations.

11.2 Derivation Hierarchy

GEDRM
  semantic reference model
        |
        v
GEDRA
  generic reference architecture
        |
        v
Enterprise Data Architecture
        |
        v
Domain Data Architecture
        |
        v
Programme / Solution Data Architecture
        |
        v
Implementation Architecture

This hierarchy is logical. An enterprise MAY derive domain architecture directly from GEDRA where no separate enterprise-level artifact is required.

Downstream architectures SHOULD preserve upstream semantic and architectural intent.

11.3 Derivation Principle

Derivation means specialization and contextualization. It does not mean unrestricted reinterpretation.

A derived architecture MAY:

select relevant GEDRA planes;
select relevant reusable patterns;
select relevant views;
introduce enterprise/domain-specific concepts;
map generic roles to named capabilities;
define stricter controls;
define lifecycle states;
define technical standards;
define implementation topology;
define operating-model responsibilities.

A derived architecture MUST NOT:

redefine GEDRM concepts incompatibly;
collapse distinctions GEDRA requires to remain explicit;
infer authority from technology;
infer product status from implementation form;
treat governance as optional where applicable;
silently replace generic GEDRA roles with conflicting local terms.

11.4 Enterprise Data Architecture Derivation

An Enterprise Data Architecture SHOULD establish how GEDRA applies across the enterprise.

It MAY define:

enterprise semantic model;
enterprise authority model;
enterprise data-product model;
common governance/control model;
enterprise platform strategy;
shared utility capabilities;
common architecture patterns;
approved specialization vocabulary;
domain boundaries;
shared conformance expectations.

The enterprise architecture SHOULD identify which GEDRA concepts or patterns are mandatory enterprise-wide and which may be specialized by domains.

11.5 Domain Data Architecture Derivation

A Domain Data Architecture SHOULD specialize GEDRA for a bounded business/data domain.

It MAY define:

domain ontology;
domain entities and relationships;
domain Systems of Record;
domain Authoritative Sources;
domain Data Products;
domain consumers;
domain-specific controls;
domain-specific lifecycle;
domain platform mappings;
domain distribution patterns.

Where a domain diverges from enterprise-level semantic or governance constraints, the divergence SHOULD be explicit.

11.6 Programme / Solution Architecture Derivation

Programme and solution architectures MAY become more implementation-specific.

They MAY define:

named systems;
services;
APIs;
topics;
tables;
storage platforms;
cloud services;
network boundaries;
runtime controls;
deployment topology;
operational ownership.

The implementation SHOULD retain traceability back to relevant GEDRA roles and patterns.

For example:

GEDRA role:
  Data Distributor

Solution implementation:
  Managed Streaming Distribution Service

or:

GEDRA concept:
  Authoritative Source

Solution implementation:
  Customer Master View in Platform X

The named technology does not replace the semantic role.

11.7 Profile Derivation

A GEDRA Profile is a governed specialization for a specific context.

Profiles MAY include:

enterprise profile;
domain profile;
regulatory profile;
platform profile;
HDIP profile;
AI/data profile;
jurisdiction profile.

A profile SHOULD state:

parent GEDRA version;
specialization scope;
added constraints;
terminology mappings;
mandatory patterns;
optional patterns;
implementation expectations;
deviations;
extension concepts.

11.8 HDIP as a GEDRA Profile

HDIP SHOULD be treated as a GEDRA-aligned specialization.

GEDRA Authoritative Source -> HDIP Authorized Data Source (ADS)
GEDRA Data Distributor -> HDIP Authorized Data Distributor (ADD)
GEDRA Data Originator -> HDIP Authorized Data Originator (ADO), if adopted

HDIP MAY add stronger readiness, authorization, registry, deployment, lifecycle, or governance requirements.

HDIP MUST NOT redefine GEDRA/GEDRM semantics incompatibly.

11.9 Derivation by Pattern Selection

A derived architecture SHOULD select reusable GEDRA patterns based on need.

For example, a regulated Data Product may select:

Scoped Authority
Authoritative Sourcing
Governed Derivation
Data Productization
Governed Distribution
Consumer Access
Policy-to-Control-to-Evidence
Lineage & Provenance

A local analytical asset may require fewer patterns.

GEDRA does not require every architecture to instantiate every pattern.

11.10 Derivation by View Selection

A derived architecture SHOULD expose views appropriate to stakeholder need.

Examples:

Executive / Governance:
  Overview / Plane View
  Governance & Assurance View

Data Architecture:
  Semantic View
  Authority View
  Lineage & Provenance View

Engineering:
  Processing, Provision & Movement View
  Technology / Utility View

Product:
  Data Platform & Product View
  Consumption & Access View
  Value & Feedback View

11.11 Normative vs Illustrative Content

Normative statements use:

MUST;
MUST NOT;
SHOULD;
SHOULD NOT;
MAY.

Illustrative diagrams, examples, technology references, lifecycle examples, or sample taxonomies do not become mandatory merely because they appear in the specification.

11.12 Core Conformance Principle

GEDRA conformance is semantic and architectural, not visual.

A derived architecture does not need to:

use the same diagram style;
use the same notation;
use the same tooling;
use the same physical topology;
deploy separate systems for each plane;
use every GEDRA pattern.

A derived architecture SHOULD preserve required meanings and responsibility boundaries.

11.13 Conformance Levels

GEDRA 0.1 defines three useful conformance levels.

Level C1 — Semantic Alignment

The architecture preserves GEDRM semantic distinctions relevant to its scope.

Examples:

SoR distinct from Authoritative Source;
Data Transformer distinct from Data Processor;
Data Asset distinct from Data Product;
Policy distinct from Control;
Metric distinct from Control Evidence.

Level C2 — Architectural Alignment

The architecture additionally preserves relevant GEDRA responsibility boundaries, planes, and patterns.

Examples:

authority is scoped;
productization is intentional;
governance is cross-cutting;
transport is distinct from distribution;
consumer access is governed.

Level C3 — Profiled Conformance

The architecture additionally conforms to a named GEDRA Profile.

Examples:

HDIP profile;
enterprise regulatory profile;
domain-specific profile.

A profile MAY define stricter obligations than GEDRA core.

11.14 Conformance Claim

A conformance claim SHOULD identify:

GEDRA Version:
Architecture Scope:
Conformance Level:
Profile:
Terminology Mapping:
Extensions:
Deviations:
Assessment Date:
Approving Authority:

11.15 Semantic Conformance

A derived architecture SHOULD preserve relevant GEDRM concepts and distinctions.

Exact terminology is not required where mapped local vocabulary is explicit and semantically compatible.

Example:

Local term:
  Certified Data Source

Mapped GEDRA/GEDRM role:
  Authoritative Source

11.16 Terminology Mapping

Where local terminology differs, maintain a mapping containing:

local term;
GEDRA/GEDRM term;
equivalence status;
scope;
caveats.

Possible statuses:

equivalent
specialization
broader
narrower
related
not-equivalent

Local naming MUST NOT conceal semantic incompatibility.

11.17 Architectural Conformance

Conformance SHOULD assess whether relevant responsibilities are represented.

Questions MAY include:

Is semantic meaning explicit?
Is authority scoped?
Is processing separated from authority?
Is productization intentional?
Are consumers and access obligations explicit?
Is governance cross-cutting?
Are controls distinguishable from metrics?
Is technology treated as enabling?

The architecture need not show every concern on one diagram.

11.18 Pattern Conformance

Where an architecture claims a GEDRA pattern, it SHOULD preserve the intent and required distinctions of that pattern.

For example, a claimed Governed Distribution Pattern SHOULD not collapse Distributor, Provider, Publisher, Transport, and Broker into one undefined generic “integration layer” where those distinctions are material.

11.19 View Conformance

A GEDRA-aligned view MAY use any notation, including boxes/arrows, ArchiMate, UML, RDF, tables, or prose.

The notation is not the conformance criterion.

11.20 Technology Independence

A conformance assessment MUST NOT require a specific vendor or technology unless defined by a profile.

GEDRA core does not require a specific cloud, database, integration platform, catalog, policy engine, or observability stack.

11.21 Omission and Applicability

A GEDRA plane, pattern, or view MAY be omitted where genuinely outside scope.

An architecture SHOULD NOT omit a concern merely because it is inconvenient to model.

Applicability SHOULD be determined by architecture scope.

11.22 Extension

A derived architecture MAY add concepts not present in GEDRA.

Extensions SHOULD be classified as:

Architectural Extension — new structural, pattern, view, or implementation concern;
Semantic Extension — new semantic concept that may belong in GEDRM;
Profile Extension — stricter/context-specific specialization of GEDRA.

11.23 Extension Governance

An extension SHOULD document:

name;
purpose;
type;
parent concept/pattern if applicable;
scope;
rationale;
compatibility;
whether upstream GEDRM/GEDRA change is proposed.

11.24 Deviation

A deviation is an intentional departure from a GEDRA recommendation or profile requirement.

A deviation SHOULD identify:

affected rule;
rationale;
risk;
scope;
approver;
duration;
remediation or review plan.

A deviation SHOULD NOT silently redefine GEDRA.

11.25 Temporary vs Permanent Deviation

A deviation MAY be temporary or permanent.

Temporary deviations SHOULD have an expiry or review date where feasible.

Permanent deviations SHOULD be treated as explicit architecture decisions.

11.26 Non-Conformance

Material non-conformance includes, for example:

using Data Processor as a synonym for technical transformer;
calling every dataset a Data Product;
treating a dashboard as a Data Control;
claiming a distributor is authoritative merely because it distributes;
treating a local cache as authoritative without designation;
defining technology as the source of semantic authority.

11.27 Conformance Assessment Method

A practical conformance assessment SHOULD use:

Define architecture scope
Select applicable GEDRA planes
Select applicable patterns
Select applicable views
Identify relevant GEDRM concepts
Map local terminology
Assess semantic distinctions
Assess architectural responsibilities
Record extensions
Record deviations
Determine conformance level
Publish conformance statement

11.28 Conformance Matrix

Dimension	Question	Result
Semantics	Are GEDRM terms preserved or mapped?	Pass/Partial/Fail
Authority	Is authority explicit and scoped?	Pass/Partial/Fail
Productization	Are Data Assets distinct from Data Products?	Pass/Partial/Fail
Governance	Are Policy/Rule/Control/Evidence distinct?	Pass/Partial/Fail
Consumption	Are consumer purpose and access governed?	Pass/Partial/Fail
Technology	Are roles independent of vendor/platform?	Pass/Partial/Fail
Extensions	Are new concepts documented?	Pass/Partial/Fail
Deviations	Are departures explicit and approved?	Pass/Partial/Fail

Profiles MAY add further rows.

11.29 Traceability

A GEDRA-aligned architecture SHOULD support traceability between:

GEDRM concept
    |
GEDRA plane / pattern
    |
Enterprise or Domain Architecture
    |
Programme / Solution Architecture
    |
Implementation

Where governance is material, traceability MAY continue:

Requirement
    |
Policy
    |
Control
    |
Evidence

11.30 Requirement-to-Architecture Traceability

A mature enterprise MAY map:

Level 1 Principle
      |
      v
Level 2 Requirement
      |
      v
GEDRM Concept
      |
      v
GEDRA Plane / Pattern
      |
      v
Implementation / Control

This is recommended as a post-GEDRA reconciliation artifact rather than a prerequisite for defining GEDRA core.

11.31 Conformance and Controls

Conformance assessment itself is not automatically a Data Control.

A conformance check MAY become a Data Control if formally governed with objective, scope, owner, frequency/trigger, expected state, outcome, evidence, and failure response.

11.32 Architecture Decision Records

Derived architectures SHOULD use Architecture Decision Records or equivalent mechanisms for material choices such as:

authority designation;
major deviation;
technology specialization;
pattern selection;
product boundary;
local terminology mapping.

GEDRA does not mandate a specific ADR format.

11.33 Version Compatibility

A derived architecture SHOULD declare the GEDRA version against which it was assessed.

A later GEDRA version SHOULD NOT silently invalidate older architectures.

Migration impact SHOULD be assessed explicitly.

11.34 Forward and Backward Compatibility

GEDRA 0.1 profiles and derived architectures SHOULD avoid unnecessary dependence on incidental wording where broader semantic intent is stable.

Future GEDRA versions SHOULD preserve stable concept meaning where possible and explicitly version incompatible architectural changes.

11.35 Conformance Evidence

An organization MAY retain:

assessment matrix;
architecture diagrams;
terminology mapping;
deviation register;
extension register;
approval record;
architecture review outcome.

GEDRA core does not require a centralized conformance repository.

11.36 Governance of Conformance

Conformance governance MAY be centralized, federated, domain-led, architecture-led, or automated in part.

The operating model is enterprise-specific.

11.37 Conformance Automation

Parts of GEDRA conformance MAY be automated in future machine-readable forms.

Potential areas include:

terminology validation;
required metadata;
profile rule checking;
relationship constraints;
architecture manifest validation;
traceability checks.

GEDRA 0.1 does not require machine-readable architecture conformance.

11.38 Derivation Anti-Patterns

Copying GEDRA Verbatim — treating the generic reference architecture as the finished enterprise architecture without contextualization.
Local Terminology Without Mapping — using enterprise-specific names that obscure GEDRA semantics.
Profile as Redefinition — using a profile to change core GEDRM/GEDRA meaning.
Technology-Driven Derivation — selecting platforms first and retrofitting roles afterward.
Selective Conformance by Convenience — ignoring applicable rules that are inconvenient.
Diagram Conformance — judging conformance by visual similarity rather than semantics.
Over-Conformance — forcing irrelevant planes, patterns, or controls into narrow scope.
Hidden Deviation — departing from GEDRA recommendations without documenting the decision.

11.39 Minimum GEDRA 0.1 Derivation Expectations

A derived architecture claiming GEDRA alignment SHOULD:

identify the GEDRA version used;
define architecture scope;
preserve applicable GEDRM semantics;
preserve applicable GEDRA responsibility boundaries;
identify relevant planes;
identify relevant patterns;
use or map terminology explicitly;
document extensions;
document deviations;
distinguish logical architecture from technology implementation;
define conformance level;
retain sufficient traceability for material decisions.

11.40 Illustrative Derivation Example

GEDRA 0.1
   |
   | select:
   | - Authority
   | - Data Product
   | - Consumer Access
   | - Governance
   |
   v
Enterprise Payments Data Architecture
   |
   | specialize:
   | Authoritative Source -> Enterprise Certified Payment Source
   | Data Distributor -> Enterprise Distribution Service
   |
   v
Payments Domain Architecture
   |
   | instantiate:
   | SoR = Payment Processing Platform
   | Authoritative Source = Payment Lifecycle Store
   | Product = Payment Lifecycle Data Product
   |
   v
Solution Architecture
   |
   | implement:
   | storage = technology A
   | API = technology B
   | event transport = technology C

The technologies may change while the semantic and architectural model remains stable.

11.41 Relationship to the Canonical Overview

The derivation and conformance criteria in this section were used to reconcile the former Generic Enterprise Data Architecture diagram into the canonical GEDRA 0.1 Overview / Plane View.

The resulting canonical view is assessed on semantic and architectural alignment rather than visual similarity alone.

Derived enterprise, domain, programme, solution, and profile-specific views MAY differ visually while preserving GEDRA meaning and responsibility boundaries.

11.42 Governing Principle

Preserve meaning and responsibility; specialize implementation.

GEDRA-aligned architectures may look different.

They should not mean different things where GEDRA defines a core semantic or architectural distinction.

12. Canonical GEDRA 0.1 Overview / Plane View

12.1 Status

The former Generic Enterprise Data Architecture diagram has been reconciled against GEDRM 0.1 and GEDRA 0.1 and is now the canonical GEDRA 0.1 Overview / Plane View.

The canonical diagram is maintained as:

BPS/static/specs/gedra/0.1/gedra-0.1-overview-plane-view-canonical.drawio.xml

It is a logical, role-based architecture view rather than a 1:1 application or technology topology.

12.2 Canonical Structure

The diagram preserves the six GEDRA planes:

Semantic & Enterprise Ontology;
Authority;
Processing, Provision & Movement;
Data Platform & Product;
Consumption & Access;
Value, Observability & Feedback.

It additionally represents:

Cross-Cutting Governance & Control; and
the Technology / Utility Foundation.

These are not additional sequential data-flow planes.

12.3 Canonical Semantic Reconciliation

The canonical view uses the following GEDRA/GEDRM terms:

Data Originator
Data Producer
System of Record
Authoritative Source
Source of Authority

Data Transformer
Data Transport / Relay
Data Provider
Data Publisher
Data Distributor
Data Broker

Data Asset
Data Product
Data Consumer
Downstream Data Product

HDIP-specific terms such as ADS and ADD are intentionally excluded from the generic canonical overview and belong in the HDIP specialization/profile.

12.4 Canonical Authority Semantics

The Authority Plane preserves:

Data Originator != Data Producer
System of Record != Authoritative Source
Authoritative Source != Source of Authority
Authorized != Authoritative

Authority remains scoped and may be distributed.

The visual progression MUST NOT be interpreted as requiring every Authoritative Source to be physically downstream of a System of Record.

12.5 Canonical Processing, Provision & Movement Semantics

The canonical view preserves:

Data Transformer = changes or derives data
Data Transport / Relay = carries data
Data Provider = makes data available
Data Publisher = intentionally publishes
Data Distributor = delivers to permitted recipients
Data Broker = mediates provider-consumer relationships

One implementation MAY perform several of these roles.

12.6 Canonical Data Product Semantics

The canonical view preserves:

Data Product IS-A Data Asset
Data Asset DOES NOT IMPLY Data Product

Productization remains intentional and consumer-obligation-driven.

The Data Product is shown with representative product obligations including identity, accountable ownership, Product Promise, versioning, lifecycle, output ports, discoverability, and Data Contract.

12.7 Canonical Consumption Semantics

The Consumption & Access Plane preserves the distinction between:

Discovery
Suitability
Entitlement
Governed Access
Consumption

Data Policy remains a cross-cutting governance construct rather than being collapsed into Entitlement.

Consumer classes are architectural viewpoints and include downstream Data Products.

12.8 Canonical Observability Semantic Lock

GEDRA intentionally uses observability in two complementary architectural contexts.

Plane 4 — Observability Capability

Plane 4 observability concerns instrumentation of Data Assets, Data Products, and supporting platform capabilities.

Its responsibility is to:

instrument
measure
emit
expose operational signals

Examples include:

availability;
freshness;
latency;
quality;
schema compatibility;
delivery success;
usage telemetry;
technical health.

Primary question:

Can the product, asset, or platform capability be observed?

Plane 6 — Observability & Health Assessment

Plane 6 concerns interpretation and correlation of operational and consumer signals.

Its responsibility is to:

interpret
correlate
assess
compare
derive insight
drive feedback and evolution

Examples include:

product health assessment;
adoption analysis;
consumer experience;
cost and FinOps;
value realization;
contract-performance trends;
feedback;
lifecycle decisions.

Primary question:

What are the observations telling us, and what should change?

Therefore:

Plane 4 Observability Capability
    !=
Plane 6 Observability & Health Assessment

The two are complementary, not duplicate responsibilities.

12.9 Canonical Governance Semantics

The canonical view preserves the distinction between:

Data Policy
Policy as Code
Data Contract
Data Quality Rule
Data Control
Control Evidence

Control Execution is intentionally omitted from the high-level overview to avoid overloading the view; it remains first-class in the detailed Governance & Assurance View.

12.10 Canonical Technology Boundary

Technology / Utility is shown as the enabling foundation.

Technology does not establish:

semantic meaning;
authority;
ownership;
Data Product status.

The canonical view therefore remains technology-neutral.

12.11 Canonical Status Rule

The canonical Overview / Plane View MAY be specialized or projected into enterprise, domain, programme, solution, or profile-specific views.

Such derived views MAY look different.

They SHOULD preserve the same GEDRA semantic and architectural distinctions.

13. Profiles & HDIP Specialization

13.1 Purpose

GEDRA Profiles define governed specializations of the generic reference architecture for a particular enterprise, domain, regulatory context, platform, or operating model.

This section formalizes how profiles extend GEDRA while preserving GEDRM/GEDRA semantics.

HDIP is the principal reference specialization used in GEDRA 0.1.

13.2 Profile Principle

A GEDRA Profile MAY make the generic architecture stricter.

It MUST NOT make the generic semantics different.

The governing rule is:

Specialize constraints, obligations, and implementation; preserve meaning.

13.3 Profile Responsibilities

A profile SHOULD define:

parent GEDRA version;
profile identity and version;
scope;
terminology mappings;
additional roles or specializations;
mandatory and optional GEDRA patterns;
stricter cardinalities or requirements;
lifecycle states;
architecture gates;
required metadata;
runtime expectations;
conformance additions;
deviations from the parent profile, where allowed.

13.4 Permitted Profile Specialization

A profile MAY:

specialize a generic GEDRM/GEDRA role;
introduce profile-specific qualification criteria;
define stricter governance obligations;
require specific registries or metadata;
define platform/runtime realization;
define readiness gates;
define mandatory controls;
define concrete lifecycle states;
require particular views.

For example:

GEDRA:
  Authoritative Source

HDIP:
  Authorized Data Source (ADS)

is a specialization.

13.5 Prohibited Profile Redefinition

A profile MUST NOT redefine a core concept incompatibly.

For example, an HDIP profile MUST NOT assert:

ADS = System of Record

because GEDRA allows an Authoritative Source to be a System of Record, governed projection, mastered source, derived source, assembled source, or federated source.

Likewise:

ADD = Authoritative Source

would be invalid.

Authorization to distribute does not confer authority over truth.

13.6 HDIP Role Mapping

GEDRA 0.1 defines the following core HDIP mappings:

GEDRA / GEDRM	HDIP Specialization
Data Originator	Authorized Data Originator (ADO), if adopted
Authoritative Source	Authorized Data Source (ADS)
Data Distributor	Authorized Data Distributor (ADD)
Data Product	HDIP Data Product
AI Product	HDIP/AIPS AI Product
Data Platform & Product Plane	HDIP platform/product capabilities
Cross-Cutting Governance & Control	HDIP governance and runtime policy model
Technology / Utility Foundation	HDIP enabling runtime and utility capabilities

13.7 Authorized Data Source

HDIP ADS is a governed specialization of GEDRA Authoritative Source.

An ADS SHOULD therefore retain all Authoritative Source semantics and additionally satisfy HDIP-specific authorization criteria.

Conceptually:

Authoritative Source
        |
        | specialized by
        v
Authorized Data Source (ADS)

The authorization criteria are profile-specific.

They do not alter the meaning of Authoritative Source.

13.8 Authorized Data Distributor

HDIP ADD is a governed specialization of GEDRA Data Distributor.

Conceptually:

Data Distributor
        |
        | specialized by
        v
Authorized Data Distributor (ADD)

ADD MAY impose stronger requirements concerning:

approved distribution;
consumer entitlement;
policy enforcement;
movement controls;
observability;
evidence;
approved interfaces.

ADD MUST NOT be interpreted as authoritative merely because it is authorized.

13.9 Authorized Data Originator

If HDIP adopts ADO, it SHOULD be modeled as a specialization of Data Originator.

Conceptually:

Data Originator
        |
        | specialized by
        v
Authorized Data Originator (ADO)

ADO qualification MAY add enterprise authorization or onboarding criteria without changing the underlying meaning of origination.

13.10 HDIP Data Product

An HDIP Data Product is a GEDRA Data Product subject to HDIP-specific platform, governance, productization, and lifecycle constraints.

It therefore inherits:

Data Asset specialization;
accountable ownership;
stable identity;
Product Promise;
versioning;
lifecycle;
discoverability;
governed output ports;
consumer-facing obligations.

HDIP MAY add:

registries;
readiness gates;
deployment qualification;
runtime policy binding;
platform conformance;
economic accountability;
operational support requirements.

13.11 HDIP Product-Local Governance

GEDRA supports the generic pattern:

Applicable Policy
      |
      v
Policy Resolution
      |
      v
Resolved Governance Bundle
      |
      +-- Policy as Code
      +-- Data Contract
      +-- Data Quality Rules
      +-- Data Controls
      +-- Provenance / Evidence Definitions

HDIP MAY specialize this by binding the resolved governance bundle to an exact published/deployed Data Product version.

This is an HDIP runtime specialization of a generic GEDRA pattern.

13.12 HDIP Registries

HDIP MAY require registries such as:

ADS Registry;
Data Product Registry;
Schema Registry;
Policy Registry;
Capability Registry;
Blueprint Registry;
other governed runtime/product registries.

These are HDIP implementation and operating-model choices.

GEDRA does not require all enterprises to implement the same registry set.

13.13 HDIP Data Mesh

GEDRA is compatible with Data Mesh but does not require a Data Mesh operating model.

An HDIP Data Mesh profile MAY specialize GEDRA by defining:

domain-aligned ownership;
federated governance;
productization expectations;
platform self-service;
product discovery;
cross-domain interoperability.

The generic GEDRA semantics remain unchanged.

13.14 AI Product Specialization

AI Products MAY be governed through AIPS and HDIP while remaining aligned with GEDRA data obligations.

AI Product specialization SHOULD preserve relevant:

training/inference data semantics;
authority context;
lineage;
privacy;
policy;
quality;
versioning;
evidence;
consumer obligations.

AI productization does not create an exemption from data governance.

13.15 HDIP Architecture Views

An HDIP profile MAY provide dedicated views such as:

HDIP Overview;
HDIP Data Product lifecycle;
HDIP AI Product lifecycle;
ADS/ADD flow;
governance/runtime policy view;
registry interaction view;
consumer access view;
observability/value view.

These views SHOULD map back to GEDRA planes and patterns.

13.15.1 HDIP Logical Architecture Mapping

The established HDIP logical architecture MAY retain HDIP-specific plane and layer names, provided their relationship to GEDRA is explicit.

A canonical mapping is:

HDIP Logical Architecture Construct	Primary GEDRA Alignment	Interpretation
Product Development Experience Plane (PDEP)	Data Platform & Product Plane; Cross-Cutting Governance & Control	HDIP product-development specialization supporting governed Data Product and AI Product creation, qualification, compilation, and publication
Marketplace & Consumption Layer	Consumption & Access Plane; Processing, Provision & Movement Plane	Product discovery, access, onboarding, provision, publication/distribution, and governed consumption
Consumer Experience Plane (CEP)	Consumption & Access Plane	Consumer-facing access modes, APIs, queries, agents, workflows, dashboards, and other consumption experiences
Consumer Observability & Value Plane (COVP)	Value, Observability & Feedback Plane	Usage, cost/FinOps, value assessment, feedback, and continuous value optimization
Governance Plane	Cross-Cutting Governance & Control	Policy/control, semantic governance, platform governance, metadata, lineage, and related assurance
Infrastructure / Utility Plane	Technology / Utility Foundation	Compute, storage, processing, security, hosting, messaging, CI/CD, IAM, resilience, AI orchestration, and other enabling utilities
Data Product	Data Platform & Product Plane	HDIP specialization of GEDRA Data Product
AI Product	HDIP/AIPS specialization with GEDRA data obligations	Product specialization that remains subject to relevant data semantics, authority, privacy, lineage, policy, quality, control, and evidence obligations

These HDIP names are profile constructs, not additional GEDRA core planes.

For example:

PDEP != GEDRA core plane
COVP != GEDRA core plane
CEP != GEDRA core plane

They are HDIP organization choices that project and compose GEDRA responsibilities.

13.16 HDIP Pattern Mapping

HDIP SHOULD reuse GEDRA patterns rather than recreate semantically overlapping patterns.

Examples:

GEDRA Scoped Authority
    -> HDIP ADS qualification

GEDRA Governed Distribution
    -> HDIP ADD distribution

GEDRA Data Productization
    -> HDIP Data Product lifecycle

GEDRA Policy-to-Control-to-Evidence
    -> HDIP product-local governance runtime

GEDRA Consumer Access
    -> HDIP entitlement and product access

GEDRA Feedback & Product Evolution
    -> HDIP product health and economic accountability

13.17 Profile Conformance

An architecture claiming HDIP-profiled GEDRA conformance SHOULD satisfy:

GEDRA C1 Semantic Alignment
        +
GEDRA C2 Architectural Alignment
        +
HDIP Profile Requirements
        =
GEDRA C3 Profiled Conformance

13.18 Profile Terminology Mapping

Every profile-specific term SHOULD map explicitly to its generic parent where one exists.

For example:

ADS -> Authoritative Source
ADD -> Data Distributor
ADO -> Data Originator

A profile-specific term without a generic parent MAY be:

a local architectural extension;
a profile concept;
or a candidate GEDRM semantic extension.

The classification SHOULD be explicit.

13.18.1 HDIP Lifecycle and Gate Semantics

HDIP product-development steps, readiness gates, deployment gates, and product lifecycle states are profile-level operating constructs.

They MAY make GEDRA stricter, for example by requiring:

defined product-development stages;
readiness criteria;
publication qualification;
deployment approval;
registry completion;
runtime-policy binding;
evidence completion.

They MUST NOT be interpreted as changing the underlying GEDRM/GEDRA meaning of Data Asset, Data Product, Authoritative Source, Data Distributor, Data Control, or other generic concepts.

AIPS-specific AI Product gates are likewise AI-product profile constraints rather than GEDRA core lifecycle states.

13.19 Profile Evolution

A profile SHOULD version changes that alter:

qualification criteria;
lifecycle;
mandatory controls;
runtime obligations;
terminology mappings;
conformance requirements.

Profile evolution SHOULD NOT silently alter GEDRA core semantics.

13.20 HDIP Specialization Anti-Patterns

The following are anti-patterns:

ADS Equals SoR — treating the two as universally synonymous.
ADD Equals Authority — treating distribution authorization as truth authority.
HDIP Term Becomes GEDRA Core — leaking profile-specific terminology into generic GEDRA.
Platform Capability Equals Product — treating HDIP services as Data Products automatically.
Profile Rewrites Semantics — changing GEDRM/GEDRA meaning instead of specializing it.
Registry Presence Equals Conformance — treating registration as sufficient productization/governance.
Data Mesh Equals GEDRA — assuming GEDRA requires one operating model.
AI Exception — weakening ordinary data-governance obligations because the consumer/product is AI.

13.21 Minimum HDIP Profile Alignment Expectations

An HDIP-aligned architecture SHOULD demonstrate that:

ADS maps to Authoritative Source;
ADD maps to Data Distributor;
ADO, if used, maps to Data Originator;
authorized and authoritative remain distinct;
HDIP Data Products preserve GEDRA Data Product semantics;
platform services are not automatically Data Products;
product-local governance remains traceable to authoritative policy;
registries support rather than redefine semantic identity;
the HDIP prerequisite registry set is explicit where adopted, including ADS, Product, Schema, Policy, Capability, and Blueprint registries;
HDIP-specific requirements are identifiable as profile constraints;
HDIP logical architecture constructs such as PDEP, CEP, COVP, Governance Plane, and Utility Plane are traceable to GEDRA responsibilities;
generic GEDRA views remain understandable without HDIP terminology;
AI productization preserves relevant data-governance obligations;
HDIP/AIPS lifecycle and readiness gates remain profile constraints rather than GEDRA core semantics;
profile changes are versioned and impact-assessable.

13.22 HDIP Specialization Principle

The canonical relationship is:

GEDRM
  defines semantic meaning
        |
        v
GEDRA
  organizes generic architecture
        |
        v
HDIP Profile
  specializes Data & AI architecture
        |
        v
Enterprise / Domain / Programme Implementation

HDIP is therefore a specialization of GEDRA, not the definition of GEDRA itself.

14. GEDRA 0.1 Semantic Consistency & Closure

14.1 Purpose

This section records the semantic consistency review performed across GEDRA 0.1 before post-GEDRA reconciliation begins.

The review checks that the specification:

preserves GEDRM 0.1 meanings;
uses one stable six-plane architecture;
preserves cross-cutting governance and technology-foundation boundaries;
keeps generic GEDRA terminology separate from HDIP profile terminology;
avoids accidental role conflation;
keeps productization intentional;
preserves policy/control/evidence distinctions;
keeps architecture views and reusable patterns consistent with the core planes.

14.2 Semantic Closure Result

GEDRA 0.1 is assessed as internally coherent enough to enter release-candidate status.

No material contradiction was identified across the core plane model, reusable patterns, architecture views, derivation/conformance guidance, canonical overview, and HDIP specialization model.

14.3 Core Semantic Locks

The following distinctions are treated as stable GEDRA 0.1 semantic locks:

Data Originator != Data Producer

System of Record != Authoritative Source
Authoritative Source != Source of Authority
Authorized != Authoritative

Data Transformer != Data Processor

Data Transport / Relay != Data Distributor
Data Provider != Data Publisher
Data Distributor != Authoritative Source
Technical message broker != Data Broker

Data Object != Data Asset
Data Asset != Data Product
Platform Capability != Data Product
Output Port != Data Product
Catalog Entry != Data Product
Marketplace Listing != Data Product

Data Policy != Policy as Code
Data Policy != Data Control
Data Contract != Data Control
Data Quality Rule != Data Control
Metric != Data Control
Observability Signal != Control Evidence
Requirement != Data Control

Data Recipient != Data Consumer
Discovery != Entitlement
Authorization != Entitlement semantics

Usage != Value
Cost != Value

Technology Capability != Architectural Role

14.4 Stable Architectural Structure

GEDRA 0.1 adopts six logical planes:

Semantic & Enterprise Ontology
Authority
Processing, Provision & Movement
Data Platform & Product
Consumption & Access
Value, Observability & Feedback

with:

Cross-Cutting Governance & Control
Technology / Utility Foundation

These are logical architectural viewpoints rather than mandatory physical tiers.

14.5 Observability Closure

GEDRA 0.1 deliberately distinguishes two complementary observability responsibilities.

Plane 4:
Observability Capability
= instrumentation and exposure of operational signals

Plane 6:
Observability & Health Assessment
= interpretation and correlation of signals to support health,
  value, cost, feedback, and evolution decisions

The distinction is architectural rather than technological.

The same telemetry MAY participate in both contexts.

14.6 Generic vs Profile Terminology

Generic GEDRA terminology remains profile-neutral.

The following HDIP terms are specializations rather than GEDRA core replacements:

ADO -> Data Originator
ADS -> Authoritative Source
ADD -> Data Distributor

Generic GEDRA views SHOULD use the generic terms unless the view is explicitly an HDIP profile projection.

14.7 Architectural vs Semantic Extension Boundary

GEDRA MAY introduce architectural constructs such as:

planes;
patterns;
views;
profiles;
architecture-level specializations.

GEDRA MUST NOT silently create incompatible GEDRM semantic concepts.

Where a reusable semantic concept is discovered during GEDRA work, it SHOULD be recorded as candidate GEDRM feedback.

The Data Quality Control Pattern in Section 7.11 is therefore explicitly architectural unless or until separately formalized in GEDRM.

14.8 Canonical Overview Status

The reconciled diagram:

gedra-0.1-overview-plane-view-canonical.drawio.xml

is the canonical GEDRA 0.1 Overview / Plane View.

It is intentionally not a complete rendering of every GEDRA concept.

Detailed semantics remain authoritative in the normative specification and dedicated architecture views.

14.9 Known Intentional Abstractions

The canonical overview intentionally omits or compresses certain detailed concepts, including:

Control Execution;
detailed privacy role relationships;
complete lineage semantics;
complete product-governance bundles;
full Technology / Utility capability inventory;
all reusable architecture patterns.

These omissions do not alter the underlying GEDRA semantics.

14.10 Remaining Post-GEDRA Work

The remaining work is reconciliation rather than continued expansion of GEDRA core.

The planned sequence is:

R1 Level 1 principle alignment
R2 Level 2 requirement-to-GEDRA mapping
R4 GEDRM architectural-feedback review
R5 terminology consistency across all artifacts
R6 final HDIP specialization consistency

R3, the Generic Enterprise Data Architecture diagram refresh, is complete.

14.11 Release-Candidate Principle

GEDRA 0.1 should now change only where one of the following is discovered:

a genuine semantic contradiction;
a GEDRM incompatibility;
an unresolved conformance ambiguity;
a material omission required for derivability;
a reconciliation finding that demonstrates the GEDRA core is incomplete.

Editorial refinement alone SHOULD NOT destabilize the semantic baseline.

14.12 Closure Statement

GEDRA 0.1 now provides a coherent reference architecture spanning:

meaning
authority
processing
provision
movement
persistence
productization
consumption
governance
control
technology enablement
observability
value
feedback
derivation
conformance
profiles

The specification is therefore ready to move from core construction into post-GEDRA enterprise reconciliation.

15. Post-GEDRA Reconciliation Programme Closure

15.1 R6 — Final HDIP Specialization Consistency

The final HDIP specialization review confirms that HDIP can be treated as a governed GEDRA profile/specialization without redefining GEDRM or GEDRA core semantics.

The following mappings are closed for GEDRA 0.1:

Data Originator      -> Authorized Data Originator (ADO), if adopted
Authoritative Source -> Authorized Data Source (ADS)
Data Distributor     -> Authorized Data Distributor (ADD)
Data Product         -> HDIP Data Product
AI Product           -> HDIP/AIPS AI Product specialization

The following distinctions remain mandatory:

ADS != System of Record
ADD != Authoritative Source
Authorized != Authoritative

HDIP Data Product IS-A GEDRA Data Product
HDIP platform capability != Data Product

HDIP logical plane/layer != GEDRA core plane
HDIP readiness/lifecycle gate != GEDRA core semantic state

15.2 HDIP Logical Architecture Closure

HDIP's established logical architecture is treated as a profile projection of GEDRA.

It MAY organize implementation and operating responsibilities through constructs such as:

Product Development Experience Plane (PDEP)
Marketplace & Consumption Layer
Consumer Experience Plane (CEP)
Consumer Observability & Value Plane (COVP)
Governance Plane
Infrastructure / Utility Plane

These names are retained as HDIP-specific organization constructs.

They do not replace or redefine the six GEDRA planes.

15.3 Product-Local Governance Closure

HDIP MAY resolve applicable governance during product development and bind the resulting governed bundle to a published/deployed product version.

The bundle MAY include:

Policy as Code
Data Contract
Data Quality Rules
Data Controls
provenance / lineage requirements
evidence definitions
schema and semantic commitments

This runtime optimization MUST remain traceable to authoritative policy and governance decisions.

Central or federated governance capabilities remain responsible for policy authoring, applicability, approval, lifecycle, versioning, and change propagation as defined by the HDIP operating model.

15.4 Registry Closure

Where the established HDIP profile is used, its prerequisite registry set includes:

ADS Registry
Data Product Registry
Schema Registry
Policy Registry
Capability Registry
Blueprint Registry

Additional registries MAY be introduced by the profile.

Registry presence alone does not establish:

authority
product status
conformance
control effectiveness

Those properties remain governed by their respective GEDRM/GEDRA/HDIP semantics.

15.5 Data Mesh Closure

HDIP MAY implement a Data Mesh operating model.

GEDRA remains independent of Data Mesh.

Therefore:

GEDRA != Data Mesh
HDIP != Data Mesh

but an HDIP Data Mesh profile MAY use domain ownership, federated governance, self-service platform capabilities, product discovery, and cross-domain interoperability to realize GEDRA-aligned responsibilities.

15.6 AI Product Closure

HDIP/AIPS AI Products remain subject to relevant GEDRA data obligations.

AI-specific lifecycle gates, model governance, evaluation, deployment qualification, and runtime requirements MAY be stricter than generic Data Product obligations.

They do not remove requirements concerning:

authoritative data sourcing;
semantics;
lineage and provenance;
privacy;
access and entitlement;
Data Quality;
policy;
Data Controls;
Control Evidence;
versioning;
lifecycle;
consumer obligations.

15.7 Programme Closure Status

The post-GEDRA reconciliation programme is complete:

R1 — Level 1 principle alignment                COMPLETE
R2 — Level 2 requirement-to-GEDRA mapping      COMPLETE
R3 — Generic architecture diagram refresh      COMPLETE
R4 — GEDRM architectural-feedback review       COMPLETE
R5 — Cross-artifact terminology consistency    COMPLETE
R6 — Final HDIP specialization consistency     COMPLETE

GEDRA 0.1 is therefore semantically reconciled with:

GEDRM 0.1;
Enterprise Data Management Level 1;
Enterprise Data Management Level 2;
the canonical GEDRA Overview / Plane View;
HDIP specialization semantics.

Further changes to the 0.1 baseline SHOULD be limited to genuine contradiction, incompatibility, conformance ambiguity, or material omission.

16. Downloads

The following GEDRA 0.1 specification and machine-readable artifacts are published directly from the BPS Docusaurus static/specs/gedra/0.1/ directory.

Artifact	Purpose	Download
Architecture Registry	Canonical machine-readable registry of GEDRA construct kinds, planes, patterns, views, relationships, conformance levels, controlled vocabularies, and profile references	Download YAML
Constraint Catalogue	Canonical catalogue of GEDRA machine and assessment constraints, including stable `GEDRA-C-*` identifiers and execution responsibility	Download YAML
JSON-LD Context	Compact terms and canonical IRI mappings for GEDRA JSON-LD	Download JSON-LD
JSON Schema	Structural JSON / JSON-LD validation companion for GEDRA architecture instances, mappings, applicability statements, extensions, deviations, and conformance claims	Download JSON Schema
RDF/OWL Vocabulary	Formal GEDRA architecture vocabulary, construct definitions, relationships, and controlled architecture graph representation	Download Turtle
SHACL Shapes	Core GEDRA semantic and machine-conformance constraints	Download SHACL
Canonical Overview / Plane View	Canonical GEDRA 0.1 logical, role-based architecture view	Download Draw.io XML
Package Manifest	Release/package inventory, authority boundary, artifact hashes, profile references, and release gates	Download Manifest
Publication Index	Machine-readable entry point to the GEDRA 0.1 publication package	Download JSON
Testcase Manifest	Inventory of valid, structural-invalid, semantic-invalid/warning, and HDIP profile-invalid validation cases	Download Manifest
Conformance Runner	Automated GEDRA 0.1 JSON Schema / RDF / SHACL / profile-SHACL validation runner	Download Runner
Conformance Requirements	Python dependencies for the GEDRA conformance runner	Download Requirements
Release Notes	GEDRA 0.1 release-candidate scope, reconciliation status, lexical normalization, and release-gate notes	TBA

The HDIP 0.1 GEDRA reference-profile artifacts are published beneath /specs/gedra/0.1/profiles/hdip/0.1/:

Artifact	Purpose	Download
HDIP Reference Profile	Data-side HDIP specialization metadata, mappings, registries, requirements, and profile-owned constraints	Download YAML
HDIP JSON-LD Context	Profile-specific compact terms and IRI mappings	Download JSON-LD
HDIP RDF/OWL Profile	RDF representation of the HDIP GEDRA reference profile	Download Turtle
HDIP SHACL Shapes	Additive HDIP profile constraints used with GEDRA core SHACL	Download SHACL
HDIP JSON Schema	Additive structural profile schema composed with GEDRA core JSON Schema	Download JSON Schema

Illustrative examples are also published beneath /specs/gedra/0.1/examples/, including:

The human-readable GEDRA 0.1 specification remains the normative architectural authority even where a machine-readable artifact is downloadable. Machine validation provides conformance evidence; it does not by itself constitute architectural approval.

Appendix A — Post-GEDRA 0.1 Reconciliation Plan

After the GEDRA 0.1 core is complete:

R1 — Level 1 principle alignment;
R2 — Level 2 requirement-to-GEDRA mapping;
R3 — Generic Enterprise Data Architecture diagram refresh — completed; canonical GEDRA Overview / Plane View established;
R4 — GEDRM architectural-feedback review;
R5 — terminology consistency across all artifacts;
R6 — HDIP specialization consistency — completed; final profile mapping and logical-architecture consistency confirmed.

Expected change magnitude:

Artifact	Expected Change
Enterprise Data Management Level 1	Low
Enterprise Data Management Level 2	Low–Moderate
Generic Enterprise Data Architecture diagram	Moderate–High
GEDRM 0.1	Very Low
GEDRA 0.1	New reference architecture baseline

Appendix B — Publication Convention

GEDRA 0.1 specification artifacts MUST be maintained under:

BPS/static/specs/gedra/0.1/

Docusaurus publishes the corresponding public path as:

/specs/gedra/0.1/

This path convention MUST be used consistently for GEDRA 0.1 artifacts.

4.1 Data Architecture Is Role-Based, Not Application-Centric
4.2 Authority Is Scoped
4.3 Meaning Precedes Movement
4.4 Processing Does Not Establish Authority
4.5 Productization Is Intentional
4.6 Governance and Control Are Cross-Cutting
4.7 Consumption Shapes Architectural Obligations
4.8 Architecture Is Often Graph-Shaped
4.9 Technology Enables but Does Not Define Data Architecture
4.10 Reference Architecture Must Be Derivable
5.1 Architectural Plane
5.2 Cross-Cutting Governance & Control
5.3 Technology / Utility Foundation
5.4 Architecture Pattern
5.5 Architecture View
5.6 Profile / Specialization
6.1 Semantic & Enterprise Ontology Plane
- 6.1.1 Purpose
- 6.1.2 Architectural Responsibility
- 6.1.3 Relationship to GEDRM
- 6.1.4 Core Semantic Constructs
- 6.1.5 Enterprise Ontology and Domain Ontology
- 6.1.6 Identity, Role, and Classification
- 6.1.7 Semantic Classification Model
- 6.1.8 Canonical Semantics vs Canonical Physical Model
- 6.1.9 Critical Data Elements
- 6.1.10 External Standards and Semantic Alignment
- 6.1.11 Inputs
- 6.1.12 Outputs
- 6.1.13 Interaction with the Authority Plane
- 6.1.14 Interaction with Processing, Provision & Movement
- 6.1.15 Interaction with the Data Platform & Product Plane
- 6.1.16 Interaction with Consumption & Access
- 6.1.17 Interaction with Governance & Control
- 6.1.18 Semantic Evolution
- 6.1.19 Architectural Boundaries
- 6.1.20 Anti-Patterns
- 6.1.21 Minimum GEDRA 0.1 Conformance Expectations
- 6.1.22 Illustrative Enterprise View
6.2 Authority Plane
- 6.2.1 Purpose
- 6.2.2 Core GEDRM Roles
- 6.2.3 Core Authority Distinctions
- 6.2.4 State Authority vs Sourcing Authority vs Designation Authority
- 6.2.5 Authority Is Always Scoped
- 6.2.6 Authority May Be Distributed
- 6.2.7 Derived and Mastered Authority
- 6.2.8 Authoritative vs Authorized
- 6.2.9 HDIP Specialization
- 6.2.10 Authority Designation Pattern
- 6.2.11 Authoritative Sourcing Pattern
- 6.2.12 Interaction with the Semantic Plane
- 6.2.13 Interaction with Processing, Provision & Movement
- 6.2.14 Interaction with the Data Platform & Product Plane
- 6.2.15 Interaction with Consumption & Access
- 6.2.16 Interaction with Governance & Control
- 6.2.17 Change and Invalidation
- 6.2.18 Architectural Boundaries
- 6.2.19 Anti-Patterns
- 6.2.20 Minimum GEDRA 0.1 Conformance Expectations
- 6.2.21 Illustrative Authority View
6.3 Processing, Provision & Movement Plane
- 6.3.1 Purpose
- 6.3.2 Core GEDRM Roles
- 6.3.3 Core Role Distinctions
- 6.3.4 Processing vs Provision vs Movement
- 6.3.5 Transformation and Derivation
- 6.3.6 Processing Does Not Confer Authority
- 6.3.7 Provision vs Publication
- 6.3.8 Distribution vs Transport
- 6.3.9 Broker Semantics
- 6.3.10 Governed Distribution Pattern
- 6.3.11 Direct, Mediated, and Productized Provision
- 6.3.12 Data Contract Interaction
- 6.3.13 Policy Interaction
- 6.3.14 Privacy Interaction
- 6.3.15 Interaction with Semantic & Enterprise Ontology
- 6.3.16 Interaction with Authority Plane
- 6.3.17 Interaction with Data Platform & Product Plane
- 6.3.18 Interaction with Consumption & Access
- 6.3.19 Interaction with Governance & Control
- 6.3.20 Copies, Caches, and Replicas
- 6.3.21 Synchronous and Asynchronous Movement
- 6.3.22 Push, Pull, and Query Patterns
- 6.3.23 Data Movement Across Boundaries
- 6.3.24 Failure, Replay, and Delivery Semantics
- 6.3.25 Observability of Movement and Processing
- 6.3.26 Change and Compatibility
- 6.3.27 Architectural Boundaries
- 6.3.28 Anti-Patterns
- 6.3.29 Minimum GEDRA 0.1 Conformance Expectations
- 6.3.30 Illustrative Processing, Provision & Movement View
6.4 Data Platform & Product Plane
- 6.4.1 Purpose
- 6.4.2 Core GEDRM Concepts
- 6.4.3 Platform Capability vs Data Product
- 6.4.4 Governed Persistence
- 6.4.5 Data Asset Management
- 6.4.6 Productization Decision
- 6.4.7 Product Promise
- 6.4.8 Product Identity
- 6.4.9 Versioning
- 6.4.10 Output Ports / Product Interfaces
- 6.4.11 Discoverability
- 6.4.12 Catalog, Registry, and Marketplace Distinction
- 6.4.13 Metadata
- 6.4.14 Lineage
- 6.4.15 Data Quality
- 6.4.16 Data Contracts
- 6.4.17 Policy as Code and Product-Local Governance
- 6.4.18 Product Lifecycle
- 6.4.19 Product Ownership
- 6.4.20 Data Asset Owner vs Data Product Owner
- 6.4.21 Consumer-Centric Productization
- 6.4.22 Product vs Business Product
- 6.4.23 Product Composition
- 6.4.24 Product Dependency
- 6.4.25 Non-Owning Copies
- 6.4.26 Economic Accountability
- 6.4.27 Product Observability
- 6.4.28 Interaction with the Semantic Plane
- 6.4.29 Interaction with the Authority Plane
- 6.4.30 Interaction with Processing, Provision & Movement
- 6.4.31 Interaction with Consumption & Access
- 6.4.32 Interaction with Governance & Control
- 6.4.33 Change and Downstream Invalidation
- 6.4.34 Product Readiness
- 6.4.35 Architectural Boundaries
- 6.4.36 Anti-Patterns
- 6.4.37 Minimum GEDRA 0.1 Conformance Expectations
- 6.4.38 Illustrative Data Platform & Product View
6.5 Consumption & Access Plane
- 6.5.1 Purpose
- 6.5.2 Core GEDRM Roles
- 6.5.3 Consumer Classes
- 6.5.4 Consumer Class and Productization
- 6.5.5 Intended Use
- 6.5.6 Discovery
- 6.5.7 Suitability Assessment
- 6.5.8 Access
- 6.5.9 Entitlement
- 6.5.10 Authentication, Authorization, and Entitlement
- 6.5.11 Access Policy
- 6.5.12 Data Contract and Consumer Commitments
- 6.5.13 Consumer Access Patterns
- 6.5.14 Push and Pull Consumption
- 6.5.15 Operational Consumers
- 6.5.16 Regulatory Consumers
- 6.5.17 Risk and Finance Consumers
- 6.5.18 Analytics Consumers
- 6.5.19 AI / ML Consumers
- 6.5.20 External Consumers
- 6.5.21 Downstream Data Products as Consumers
- 6.5.22 Consumer Responsibility for Copies
- 6.5.23 Consumer-Side Transformation
- 6.5.24 Interaction with Semantic & Enterprise Ontology
- 6.5.25 Interaction with Authority Plane
- 6.5.26 Interaction with Processing, Provision & Movement
- 6.5.27 Interaction with Data Platform & Product Plane
- 6.5.28 Interaction with Governance & Control
- 6.5.29 Access Lifecycle
- 6.5.30 Least Privilege and Minimum Necessary Access
- 6.5.31 Purpose Limitation
- 6.5.32 Consumer Experience
- 6.5.33 Feedback
- 6.5.34 Consumer Impact of Change
- 6.5.35 Architectural Boundaries
- 6.5.36 Anti-Patterns
- 6.5.37 Minimum GEDRA 0.1 Conformance Expectations
- 6.5.38 Illustrative Consumption & Access View
6.6 Value, Observability & Feedback Plane
- 6.6.1 Purpose
- 6.6.2 Core Architectural Responsibilities
- 6.6.3 Observability
- 6.6.4 Observability Dimensions
- 6.6.5 Metrics Are Not Controls
- 6.6.6 Dashboards Are Not Controls
- 6.6.7 Observability Signal vs Control Evidence
- 6.6.8 Product Promise Observability
- 6.6.9 Contract Observability
- 6.6.10 Quality Observability
- 6.6.11 Usage Signals
- 6.6.12 Adoption
- 6.6.13 Cost and FinOps
- 6.6.14 Consumer Cost Attribution
- 6.6.15 Value
- 6.6.16 Value Measurement
- 6.6.17 Value vs Usage
- 6.6.18 Feedback
- 6.6.19 Feedback Loop
- 6.6.20 Feedback Into Product Evolution
- 6.6.21 Feedback Into Platform Evolution
- 6.6.22 Feedback Into Governance
- 6.6.23 Feedback Into Architecture
- 6.6.24 Incident and Problem Signals
- 6.6.25 Degradation
- 6.6.26 Product Health
- 6.6.27 Lifecycle Decision Support
- 6.6.28 Reproducibility
- 6.6.29 Interaction with Semantic & Enterprise Ontology
- 6.6.30 Interaction with Authority Plane
- 6.6.31 Interaction with Processing, Provision & Movement
- 6.6.32 Interaction with Data Platform & Product
- 6.6.33 Interaction with Consumption & Access
- 6.6.34 Interaction with Governance & Control
- 6.6.35 Alerts
- 6.6.36 SLOs, SLIs, and Product Commitments
- 6.6.37 Cost Is Not Value
- 6.6.38 Optimization
- 6.6.39 Architectural Boundaries
- 6.6.40 Anti-Patterns
- 6.6.41 Minimum GEDRA 0.1 Conformance Expectations
- 6.6.42 Illustrative Value, Observability & Feedback View
7.1 Purpose
7.2 Cross-Cutting Nature
7.3 Core Governance Domains
7.4 Core GEDRM Governance Concepts
- Data Owner
- Data Steward
- Data Custodian
- Data Product Owner
- Control Owner
- Source of Authority
7.5 Governance Artefact Chain
7.6 Data Policy
7.7 Policy as Code
7.8 Data Contract
7.9 Data Quality Rule
7.10 Data Control
7.11 Data Quality Control Pattern
7.12 Control Execution
7.13 Control Evidence
7.14 Evidence Minimum Semantics
7.15 Controls Are Not Requirements
7.16 Requirement Traceability
7.17 Governance Applicability
7.18 Policy Resolution
7.19 Product-Local Governance
7.20 Ownership and Accountability
7.21 Ownership Does Not Imply Every Operational Role
7.22 Classification Governance
7.23 Privacy Governance
7.24 Security Governance
7.25 Access Governance
7.26 Retention and Lifecycle Governance
7.27 Residency Governance
7.28 Lineage Governance
7.29 Metadata Governance
7.30 Version Governance
7.31 Exception Management
7.32 Remediation and Escalation
7.33 Preventive, Detective, and Corrective Controls
7.34 Automated and Manual Controls
7.35 Control Effectiveness
7.36 Governance by Design
7.37 Federated and Centralized Governance
7.38 Governance Across GEDRA Planes
- Semantic Plane
- Authority Plane
- Processing, Provision & Movement
- Data Platform & Product
- Consumption & Access
- Value, Observability & Feedback
7.39 Governance Interaction Model
7.40 Governance Change Propagation
7.41 Governance Currentness
7.42 Evidence Retention and Auditability
7.43 Governance Observability
7.44 Economic Accountability
7.45 Architectural Boundaries
7.46 Anti-Patterns
7.47 Minimum GEDRA 0.1 Conformance Expectations
7.48 Illustrative Cross-Cutting Governance & Control View
8.1 Purpose
8.2 Foundational Principle
8.3 Foundation Scope
8.4 Compute
8.5 Storage
8.6 Network
8.7 Identity and Access Management
8.8 Messaging and Event Infrastructure
8.9 API Infrastructure
8.10 Orchestration
8.11 CI/CD and Deployment Automation
8.12 Configuration Management
8.13 Secrets and Key Management
8.14 Runtime Hosting
8.15 Container and Platform Runtime
8.16 Backup and Disaster Recovery
8.17 Resilience
8.18 Observability Tooling
8.19 Policy Enforcement Runtime
8.20 Metadata Infrastructure
8.21 AI Orchestration
8.22 Environment Management
8.23 Utility Services
8.24 Shared vs Embedded Capability
8.25 Technology Selection Principles
8.26 Portability and Avoidance of Semantic Lock-In
8.27 Interoperability
8.28 Technology Lifecycle
8.29 Technology Change and Architectural Stability
8.30 Multi-Cloud and Hybrid Architecture
8.31 Technology and Authority
8.32 Technology and Productization
8.33 Technology and Governance
8.34 Security and Trust Boundaries
8.35 Capacity and Scalability
8.36 Performance
8.37 Cost
8.38 Operational Ownership
8.39 Service Management
8.40 Runtime Dependency Management
8.41 Recovery Semantics
8.42 Infrastructure as Code
8.43 Technology / Utility Foundation Interaction with GEDRA Planes
- Semantic Plane
- Authority Plane
- Processing, Provision & Movement
- Data Platform & Product
- Consumption & Access
- Value, Observability & Feedback
8.44 Interaction with Cross-Cutting Governance & Control
8.45 Architectural Boundaries
8.46 Anti-Patterns
- Technology-First Architecture
- Product Name Equals Role
- Platform Equals Data Architecture
- Central Platform Equals Authority
- Shared Service Everywhere
- Tool Equals Governance
- Infrastructure as Code Equals Policy as Code
- Backup Equals Authoritative Copy
- Technology Lock-In of Semantics
- AI Exception to Governance
8.47 Minimum GEDRA 0.1 Conformance Expectations
8.48 Illustrative Technology / Utility Foundation View
9.1 Purpose
9.2 Scoped Authority Pattern
- 9.2.1 Problem
- 9.2.2 Intent
- 9.2.3 Logical Pattern
- 9.2.4 Rules
- 9.2.5 Anti-Patterns
- 9.2.6 Conformance
9.3 Authoritative Sourcing Pattern
- 9.3.1 Problem
- 9.3.2 Intent
- 9.3.3 Logical Pattern
- 9.3.4 Conformance
9.4 Governed Derivation Pattern
- 9.4.1 Problem
- 9.4.2 Intent
- 9.4.3 Logical Pattern
- 9.4.4 Rules
- 9.4.5 Conformance
9.5 Governed Distribution Pattern
- 9.5.1 Problem
- 9.5.2 Intent
- 9.5.3 Logical Pattern
- 9.5.4 Responsibility Separation
- 9.5.5 HDIP Specialization
- 9.5.6 Conformance
9.6 Data Productization Pattern
- 9.6.1 Problem
- 9.6.2 Intent
- 9.6.3 Logical Pattern
- 9.6.4 Product Obligations
- 9.6.5 Boundary Rules
- 9.6.6 Conformance
9.7 Policy-to-Control-to-Evidence Pattern
- 9.7.1 Problem
- 9.7.2 Intent
- 9.7.3 Logical Pattern
- 9.7.4 Semantic Locks
- 9.7.5 Product-Local Governance
- 9.7.6 Conformance
9.8 Privacy Processing-Role Pattern
- 9.8.1 Problem
- 9.8.2 Intent
- 9.8.3 Logical Pattern
- 9.8.4 Core Rule
- 9.8.5 Conformance
9.9 Consumer Access Pattern
- 9.9.1 Problem
- 9.9.2 Intent
- 9.9.3 Logical Pattern
- 9.9.4 Rules
- 9.9.5 Conformance
9.10 Feedback and Product Evolution Pattern
- 9.10.1 Problem
- 9.10.2 Intent
- 9.10.3 Logical Pattern
- 9.10.4 Rules
- 9.10.5 Conformance
9.11 Governed Copy / Cache Pattern
- 9.11.1 Problem
- 9.11.2 Intent
- 9.11.3 Logical Pattern
- 9.11.4 Rules
- 9.11.5 Conformance
9.12 Pattern Composition
9.13 Pattern Selection Guidance
9.14 Pattern Specialization
9.15 Pattern Conformance
9.16 Pattern Anti-Pattern Principle
9.17 Illustrative Pattern Map
10.1 Purpose
10.2 View Principles
10.3 Overview / Plane View
- 10.3.1 Purpose
- 10.3.2 Logical View
- 10.3.3 Interpretation
- 10.3.4 Conformance
10.4 Semantic View
- 10.4.1 Purpose
- 10.4.2 Logical View
- 10.4.3 Required Distinctions
10.5 Authority View
- 10.5.1 Purpose
- 10.5.2 Logical View
- 10.5.3 Required Distinctions
10.6 Processing, Provision & Movement View
- 10.6.1 Purpose
- 10.6.2 Logical View
- 10.6.3 Required Distinctions
10.7 Data Platform & Product View
- 10.7.1 Purpose
- 10.7.2 Logical View
- 10.7.3 Required Distinctions
10.8 Consumption & Access View
- 10.8.1 Purpose
- 10.8.2 Logical View
- 10.8.3 Required Distinctions
10.9 Governance & Assurance View
- 10.9.1 Purpose
- 10.9.2 Logical View
- 10.9.3 Required Distinctions
10.10 Privacy View
- 10.10.1 Purpose
- 10.10.2 Logical View
- 10.10.3 Required Distinctions
10.11 Lineage & Provenance View
- 10.11.1 Purpose
- 10.11.2 Logical View
10.12 Lifecycle & Change View
- 10.12.1 Purpose
- 10.12.2 Logical View
10.13 Value, Observability & Feedback View
- 10.13.1 Purpose
- 10.13.2 Logical View
- 10.13.3 Required Distinctions
10.14 HDIP Specialization View
- 10.14.1 Purpose
- 10.14.2 Core Mapping
- 10.14.3 Specialization Rule
10.15 View Composition
10.16 View Selection Guidance
10.17 View Conformance
10.18 Relationship to the Canonical GEDRA Overview / Plane View
10.19 Illustrative View Catalogue
11.1 Purpose
11.2 Derivation Hierarchy
11.3 Derivation Principle
11.4 Enterprise Data Architecture Derivation
11.5 Domain Data Architecture Derivation
11.6 Programme / Solution Architecture Derivation
11.7 Profile Derivation
11.8 HDIP as a GEDRA Profile
11.9 Derivation by Pattern Selection
11.10 Derivation by View Selection
11.11 Normative vs Illustrative Content
11.12 Core Conformance Principle
11.13 Conformance Levels
- Level C1 — Semantic Alignment
- Level C2 — Architectural Alignment
- Level C3 — Profiled Conformance
11.14 Conformance Claim
11.15 Semantic Conformance
11.16 Terminology Mapping
11.17 Architectural Conformance
11.18 Pattern Conformance
11.19 View Conformance
11.20 Technology Independence
11.21 Omission and Applicability
11.22 Extension
11.23 Extension Governance
11.24 Deviation
11.25 Temporary vs Permanent Deviation
11.26 Non-Conformance
11.27 Conformance Assessment Method
11.28 Conformance Matrix
11.29 Traceability
11.30 Requirement-to-Architecture Traceability
11.31 Conformance and Controls
11.32 Architecture Decision Records
11.33 Version Compatibility
11.34 Forward and Backward Compatibility
11.35 Conformance Evidence
11.36 Governance of Conformance
11.37 Conformance Automation
11.38 Derivation Anti-Patterns
11.39 Minimum GEDRA 0.1 Derivation Expectations
11.40 Illustrative Derivation Example
11.41 Relationship to the Canonical Overview
11.42 Governing Principle
12.1 Status
12.2 Canonical Structure
12.3 Canonical Semantic Reconciliation
12.4 Canonical Authority Semantics
12.5 Canonical Processing, Provision & Movement Semantics
12.6 Canonical Data Product Semantics
12.7 Canonical Consumption Semantics
12.8 Canonical Observability Semantic Lock
- Plane 4 — Observability Capability
- Plane 6 — Observability & Health Assessment
12.9 Canonical Governance Semantics
12.10 Canonical Technology Boundary
12.11 Canonical Status Rule
13.1 Purpose
13.2 Profile Principle
13.3 Profile Responsibilities
13.4 Permitted Profile Specialization
13.5 Prohibited Profile Redefinition
13.6 HDIP Role Mapping
13.7 Authorized Data Source
13.8 Authorized Data Distributor
13.9 Authorized Data Originator
13.10 HDIP Data Product
13.11 HDIP Product-Local Governance
13.12 HDIP Registries
13.13 HDIP Data Mesh
13.14 AI Product Specialization
13.15 HDIP Architecture Views
- 13.15.1 HDIP Logical Architecture Mapping
13.16 HDIP Pattern Mapping
13.17 Profile Conformance
13.18 Profile Terminology Mapping
- 13.18.1 HDIP Lifecycle and Gate Semantics
13.19 Profile Evolution
13.20 HDIP Specialization Anti-Patterns
13.21 Minimum HDIP Profile Alignment Expectations
13.22 HDIP Specialization Principle
14.1 Purpose
14.2 Semantic Closure Result
14.3 Core Semantic Locks
14.4 Stable Architectural Structure
14.5 Observability Closure
14.6 Generic vs Profile Terminology
14.7 Architectural vs Semantic Extension Boundary
14.8 Canonical Overview Status
14.9 Known Intentional Abstractions
14.10 Remaining Post-GEDRA Work
14.11 Release-Candidate Principle
14.12 Closure Statement
15.1 R6 — Final HDIP Specialization Consistency
15.2 HDIP Logical Architecture Closure
15.3 Product-Local Governance Closure
15.4 Registry Closure
15.5 Data Mesh Closure
15.6 AI Product Closure
15.7 Programme Closure Status

1. Purpose

2. Scope

3. Relationship to GEDRM

4. Architectural Principles

4.1 Data Architecture Is Role-Based, Not Application-Centric​

4.2 Authority Is Scoped​

4.3 Meaning Precedes Movement​

4.4 Processing Does Not Establish Authority​

4.5 Productization Is Intentional​

4.6 Governance and Control Are Cross-Cutting​

4.7 Consumption Shapes Architectural Obligations​

4.8 Architecture Is Often Graph-Shaped​

4.9 Technology Enables but Does Not Define Data Architecture​

4.10 Reference Architecture Must Be Derivable​

5. Architectural Meta-Model

5.1 Architectural Plane​

5.2 Cross-Cutting Governance & Control​

5.3 Technology / Utility Foundation​

5.4 Architecture Pattern​

5.5 Architecture View​

5.6 Profile / Specialization​

6. Initial Plane Set

6.1 Semantic & Enterprise Ontology Plane​

6.1.1 Purpose​

6.1.2 Architectural Responsibility​

6.1.3 Relationship to GEDRM​

6.1.4 Core Semantic Constructs​

Business Concept​

Entity​

Attribute / Property​

Semantic Relationship​

Taxonomy / Controlled Vocabulary​

Semantic Mapping​

6.1.5 Enterprise Ontology and Domain Ontology​

6.1.6 Identity, Role, and Classification​

6.1.7 Semantic Classification Model​

6.1.8 Canonical Semantics vs Canonical Physical Model​

6.1.9 Critical Data Elements​

6.1.10 External Standards and Semantic Alignment​

6.1.11 Inputs​

6.1.12 Outputs​

6.1.13 Interaction with the Authority Plane​

6.1.14 Interaction with Processing, Provision & Movement​

6.1.15 Interaction with the Data Platform & Product Plane​

6.1.16 Interaction with Consumption & Access​

6.1.17 Interaction with Governance & Control​

6.1.18 Semantic Evolution​

6.1.19 Architectural Boundaries​

6.1.20 Anti-Patterns​

6.1.21 Minimum GEDRA 0.1 Conformance Expectations​

6.1.22 Illustrative Enterprise View​

6.2 Authority Plane​

6.2.1 Purpose​

6.2.2 Core GEDRM Roles​

Data Originator​

Data Producer​

System of Record​

Authoritative Source​

Source of Authority​

6.2.3 Core Authority Distinctions​

6.2.4 State Authority vs Sourcing Authority vs Designation Authority​

6.2.5 Authority Is Always Scoped​

6.2.6 Authority May Be Distributed​

6.2.7 Derived and Mastered Authority​

6.2.8 Authoritative vs Authorized​

6.2.9 HDIP Specialization​

6.2.10 Authority Designation Pattern​

6.2.11 Authoritative Sourcing Pattern​

6.2.12 Interaction with the Semantic Plane​

6.2.13 Interaction with Processing, Provision & Movement​

6.2.14 Interaction with the Data Platform & Product Plane​

6.2.15 Interaction with Consumption & Access​

6.2.16 Interaction with Governance & Control​

6.2.17 Change and Invalidation​

6.2.18 Architectural Boundaries​

6.2.19 Anti-Patterns​

6.2.20 Minimum GEDRA 0.1 Conformance Expectations​

6.2.21 Illustrative Authority View​

6.3 Processing, Provision & Movement Plane​

6.3.1 Purpose​

4.1 Data Architecture Is Role-Based, Not Application-Centric

4.2 Authority Is Scoped

4.3 Meaning Precedes Movement

4.4 Processing Does Not Establish Authority

4.5 Productization Is Intentional

4.6 Governance and Control Are Cross-Cutting

4.7 Consumption Shapes Architectural Obligations

4.8 Architecture Is Often Graph-Shaped

4.9 Technology Enables but Does Not Define Data Architecture

4.10 Reference Architecture Must Be Derivable

5.1 Architectural Plane

5.2 Cross-Cutting Governance & Control

5.3 Technology / Utility Foundation

5.4 Architecture Pattern

5.5 Architecture View

5.6 Profile / Specialization

6.1 Semantic & Enterprise Ontology Plane

6.1.1 Purpose

6.1.2 Architectural Responsibility

6.1.3 Relationship to GEDRM

6.1.4 Core Semantic Constructs

Business Concept

Entity

Attribute / Property

Semantic Relationship

Taxonomy / Controlled Vocabulary

Semantic Mapping

6.1.5 Enterprise Ontology and Domain Ontology

6.1.6 Identity, Role, and Classification

6.1.7 Semantic Classification Model

6.1.8 Canonical Semantics vs Canonical Physical Model

6.1.9 Critical Data Elements

6.1.10 External Standards and Semantic Alignment

6.1.11 Inputs

6.1.12 Outputs

6.1.13 Interaction with the Authority Plane

6.1.14 Interaction with Processing, Provision & Movement

6.1.15 Interaction with the Data Platform & Product Plane

6.1.16 Interaction with Consumption & Access

6.1.17 Interaction with Governance & Control

6.1.18 Semantic Evolution

6.1.19 Architectural Boundaries

6.1.20 Anti-Patterns

6.1.21 Minimum GEDRA 0.1 Conformance Expectations

6.1.22 Illustrative Enterprise View

6.2 Authority Plane

6.2.1 Purpose

6.2.2 Core GEDRM Roles

Data Originator

Data Producer

System of Record

Authoritative Source

Source of Authority

6.2.3 Core Authority Distinctions

6.2.4 State Authority vs Sourcing Authority vs Designation Authority

6.2.5 Authority Is Always Scoped

6.2.6 Authority May Be Distributed

6.2.7 Derived and Mastered Authority

6.2.8 Authoritative vs Authorized

6.2.9 HDIP Specialization

6.2.10 Authority Designation Pattern

6.2.11 Authoritative Sourcing Pattern

6.2.12 Interaction with the Semantic Plane

6.2.13 Interaction with Processing, Provision & Movement

6.2.14 Interaction with the Data Platform & Product Plane

6.2.15 Interaction with Consumption & Access

6.2.16 Interaction with Governance & Control

6.2.17 Change and Invalidation

6.2.18 Architectural Boundaries

6.2.19 Anti-Patterns

6.2.20 Minimum GEDRA 0.1 Conformance Expectations

6.2.21 Illustrative Authority View

6.3 Processing, Provision & Movement Plane

6.3.1 Purpose

6.3.2 Core GEDRM Roles

Data Transformer

Data Transport / Relay

Data Provider

Data Publisher

Data Distributor