Organizational Data Model¶
The Organizational Data Model defines the canonical data, semantic, knowledge, and governance model of the organization.
It provides a common structure for describing:
- organizational concepts
- people, teams, and departments
- systems and data sources
- processes and operational activities
- datasets and documents
- metrics and KPIs
- relationships between organizational entities
- source fields and their canonical meanings
- observability and operational telemetry
The model is a living system. It evolves as organizational domains are discovered, defined, mapped, validated, and used.
Explore the Model¶
Ontology¶
The ontology defines the minimum stable concepts and relationships used to describe the organization.
The ontology provides the semantic foundation for the rest of the model. It is intentionally kept small and is expanded only when real domains demonstrate that additional concepts are necessary.
Data Dictionary¶
The Data Dictionary contains canonical definitions for the organization's concepts, metrics, KPIs, and data assets.
Definitions are maintained as machine readable YAML and validated against schemas before being published through the documentation site.
Domains¶
Domains apply the model to specific areas of the organization.
Each domain may contain different combinations of:
- domain concepts
- source systems
- source fields
- field matrices
- canonical mappings
- metrics
- KPIs
- operational definitions
- supporting documentation
Social Media¶
The Social Media domain models the organization's external social media presence and the measurements produced by social platforms.
The domain currently covers:
- X
- TikTok
Social Media provides a practical example of how platform specific fields are mapped into canonical organizational concepts and metrics.
Observability¶
The Observability domain models the telemetry produced by the organization's applications and supporting infrastructure.
- Overview
- Metrics Catalogue
- OTel Fields and Attributes
- Field Matrix
- Canonical Mappings
- Minimum Observability Ontology
The domain currently covers:
- application metrics
- HTTP and API telemetry
- database telemetry
- external service telemetry
- runtime and system metrics
- logs
- distributed traces
- OpenTelemetry resources, attributes, and fields
The Observability domain demonstrates how technical telemetry can be connected to the wider organizational data model without making infrastructure specific terminology part of the organization's canonical semantic layer.
Finance¶
The Finance domain models financial information, systems, processes, and measurements used by the organization.
The domain will evolve as financial systems, data sources, processes, metrics, and reporting requirements are formally mapped.
People¶
The People domain models people related information and organizational structures.
The domain will evolve as employee, team, departmental, and organizational processes are mapped into the model.
Projects¶
The Projects domain models projects, project activities, delivery information, and related organizational data.
The domain will evolve as project management processes, systems, datasets, and measurements are defined.
Products¶
The Products domain models the organization's products, their supporting systems, processes, and associated measurements.
The domain will evolve as product concepts, data sources, operational processes, and metrics are defined.
Organizational Operations¶
The Organizational Operations domain models the processes and operational activities through which the organization functions.
This domain provides a place for cross functional operational concepts that do not belong exclusively to Finance, People, Projects, Products, or another specialized domain.
How the Model Fits Together¶
The model separates organizational meaning from the systems and sources that happen to represent that meaning.
A simplified flow is:
Source Systems
↓
Source Fields / Telemetry
↓
Field Matrix
↓
Canonical Mappings
↓
Canonical Concepts
↓
Metrics / KPIs / Data Assets
↓
Organizational Knowledge
↓
Decision Making
The exact path differs by domain.
For example, an observability metric may originate from an OpenTelemetry instrument, while a social media metric may originate from a platform API field. Both can ultimately map into concepts that have meaning within the organizational model.
A source field is therefore not automatically a canonical definition.
The model distinguishes between:
- what a source calls something
- what the organization means by it
- how that meaning is measured
- where the information comes from
- how the information is used
This separation allows different systems to be integrated without forcing their terminology or structures into the organization's semantic model.
From Sources to Meaning¶
Each domain can progressively move through a common modelling process:
Domain Discovery
↓
Source Identification
↓
Source Fields / Attributes
↓
Field Matrix
↓
Canonical Mappings
↓
Canonical Definitions
↓
Metrics and KPIs
↓
Ontology Relationships
Not every domain needs every layer immediately.
A domain can begin with an overview and source discovery and become more structured as its requirements become better understood.
This prevents the model from requiring a complete ontology or data dictionary before useful work can begin.
Repository as Source of Truth¶
The repository is the source of truth for the organizational model.
Machine Readable Definitions
↓
Schema Validation
↓
Generated Documentation
↓
Human Review
↓
Evolving Organizational Model
Where structured definitions exist, they should be maintained in machine readable form and validated before publication.
Documentation provides the human readable representation of the model, while the underlying definitions provide the structured representation that can later support data engineering, governance, lineage, search, and AI systems.
Model Philosophy¶
The model follows several principles.
Start Small¶
The objective is not to create a massive ontology before the organization has enough evidence to justify one.
The model begins with a minimum stable set of concepts and expands when real domains expose gaps.
Separate Meaning from Representation¶
A database column, API field, telemetry attribute, or spreadsheet heading is a representation of information.
It is not necessarily the organization's canonical meaning.
Model Real Domains¶
Domains should be developed from actual organizational systems, processes, data, and decisions rather than theoretical classifications.
Preserve Source Context¶
Source terminology and structure remain important because they explain where information originates and how it is represented.
Canonical mappings connect that source context to the organizational model rather than replacing it.
Evolve Through Evidence¶
When a domain exposes a missing concept, relationship, metric, or definition, the model can evolve.
The objective is therefore not perfection at the beginning.
The objective is to establish a durable semantic foundation that becomes more precise as organizational knowledge grows.
Current State¶
The model currently contains structured work across several domains.
Social Media establishes the source to canonical mapping pattern using external platform data.
Observability establishes the pattern for technical telemetry, including OpenTelemetry fields, metrics, logs, traces, and canonical mappings.
Other organizational domains currently provide the structure for continued discovery and modelling:
- Finance
- People
- Projects
- Products
- Organizational Operations
These domains will become progressively more detailed as their underlying systems, processes, data assets, metrics, and organizational concepts are discovered and validated.
Where the Model Is Going¶
The Organizational Data Model is intended to become a shared semantic foundation for the organization's data ecosystem.
Over time it can support:
- data integration
- data governance
- data lineage
- data quality
- organizational reporting
- metric standardization
- institutional memory
- knowledge discovery
- AI systems
- cross domain analysis
The model does not attempt to solve all of these problems directly.
Its primary purpose is to establish a consistent understanding of what the organization has, what it means, where it comes from, how it relates, and how it is measured.