Cross-Domain Relationships

Cross-domain relationships define how entities from different Triodian domains connect, influence, and depend on one another. Unlike inter-unit relationships (which focus on organizational unit interactions), cross-domain relationships capture the semantic connections between domain types—such as how Finance funds Initiatives, or how Capabilities enable Value Streams.

Schema: cross-domain-relationship.schema.json
Specification: JSON Schema Draft-07

Overview

Why Cross-Domain Relationships Matter

Organizations don't operate in isolated functional silos. Strategies depend on capabilities, initiatives consume resources, value streams require information, and policies constrain activities across multiple domains. Cross-domain relationships make these connections explicit, enabling:

• Impact analysis — Understand how changes in one domain ripple across others
• Dependency mapping — Trace what enables, constrains, or blocks progress
• Governance alignment — Ensure policies and controls reach the right domains
• Strategic coherence — Connect high-level strategy to operational execution

A Relationship Is a Record

Each cross-domain relationship is a record with its own identifier. It names a source domain, a target domain, one of 37 relationship types and a description of how the two interact. Where the relationship is between specific records rather than between domains in general, sourceEntityID and targetEntityID carry the IDs of those records. Optional metadata records priority, impact area, frequency, strength, conditions and dates.

Direction Rule

Every relationship flows from an initiating source to a receiving target. Active domains (such as strategy, capability, valueStream, initiative, policy and stakeholder) typically initiate relationships. The passive domains information, performance, product and service receive relationships and cannot be the source; the schema rejects a record whose sourceDomain is one of them. To express, for example, that information shapes a strategy, model the domain that produces or applies the information (such as intelligence) as the source, or reverse the relationship (strategy consumes information). See Relationship Directionality.

Relationship Categories

Cross-domain relationships are organized into seven categories, each capturing a distinct type of interaction between domains. The categories group the 37 values of relationshipType; they are not a separate field.

Financial Relationships

Financial relationships describe how economic resources flow between domains and how financial performance is measured.

Relationship	Description	Example
funds	Provides financial resources to enable the target's development, operation or enhancement	Finance funds an Initiative
measures	Expresses the target's activities, outputs or outcomes in measurable financial terms	Finance measures a Capability's ROI
reports	Produces formal reports on the target's financial performance, costs or returns	Finance reports on Value Stream profitability
forecasts	Projects the target's future financial needs, costs or revenues	Finance forecasts Initiative costs

{
  "relationshipID": "CDR-001",
  "sourceDomain": "finance",
  "targetDomain": "capability",
  "relationshipType": "funds",
  "description": "Finance provides funding to capabilities to enable development and enhancement of organizational competencies aligned with strategic objectives",
  "metadata": {
    "priority": "critical",
    "impactArea": "strategic",
    "frequency": "quarterly",
    "strength": 5
  }
}

Operational Relationships

Operational relationships capture how domains enable, constrain, or depend on each other during day-to-day execution.

Relationship	Description	Example
depends	Receives necessary resources, services or capabilities from the target to deliver its outputs	Initiative depends on Capability
constrains	Imposes limitations, standards or compliance requirements on the target	Policy constrains Value Stream
enables	Is essential to the implementation, operationalization or fulfilment of the target	Technology enables Capability
mitigates	Actively reduces the risks or vulnerabilities of the target	Capability mitigates Risk
consumes	Uses, relies on or draws from the target's resources, outputs or services	Value Stream consumes Information
delivers	Provides specific value or outcomes to the target	Value Stream delivers to Customer
optimizes	Improves the performance or efficiency of the target	Initiative optimizes Capability
maintains	Ensures the ongoing operation of the target	Technology maintains Information

{
  "relationshipID": "CDR-010",
  "sourceDomain": "capability",
  "sourceEntityID": "CAP-CDM-001",
  "targetDomain": "valueStream",
  "targetEntityID": "VS-ONB-001",
  "relationshipType": "enables",
  "description": "Customer data management capability enables the customer onboarding value stream",
  "metadata": {
    "priority": "critical",
    "impactArea": "customer",
    "frequency": "continuous",
    "strength": 5
  }
}

Governance Relationships

Governance relationships define oversight, accountability, and control mechanisms across domains.

Relationship	Description	Example
monitors	Oversees, measures or evaluates the target's performance or effectiveness	Risk monitors Initiative
governs	Defines policies, standards or decision rights that control the target	Policy governs Capability
audits	Formally examines the target for compliance, performance or quality	Organization (compliance function) audits Value Stream
certifies	Provides formal approval or certification to the target	Policy certifies Technology
escalates	Receives escalated issues or exceptions from the target	Risk escalates Initiative issues
accountableFor	Is accountable for oversight of the target	Stakeholder accountableFor Initiative
responsibleFor	Has a clear line of responsibility for the target	Organization responsibleFor Capability

The compliance function is an organization unit, so a compliance audit has organization as its source domain:

{
  "relationshipID": "CDR-008",
  "sourceDomain": "organization",
  "targetDomain": "valueStream",
  "relationshipType": "audits",
  "description": "Compliance function audits customer onboarding value stream for regulatory adherence",
  "metadata": {
    "priority": "critical",
    "impactArea": "regulatory",
    "frequency": "quarterly",
    "strength": 5
  }
}

Information and Knowledge Relationships

These relationships describe how knowledge, data, and insights flow between domains. Because information and performance cannot be a source, the source is the domain that produces or applies the knowledge.

Relationship	Description	Example
informs	Provides information or data that shapes decisions in the target	Intelligence informs Strategy
validates	Confirms or verifies the target's outputs, decisions or processes	Stakeholder validates Initiative
enriches	Enhances the data quality, completeness or value of the target	Intelligence enriches Information
learns	Gains knowledge or insights from the target	Intelligence learns from Performance
teaches	Transfers knowledge or capabilities to the target	Capability teaches People
benchmarks	Uses the target as a performance standard or reference point	Finance benchmarks Market

{
  "relationshipID": "CDR-011",
  "sourceDomain": "intelligence",
  "sourceEntityID": "INT-MKT-001",
  "targetDomain": "strategy",
  "targetEntityID": "STR-EXP-001",
  "relationshipType": "informs",
  "description": "Competitive intelligence from the market analysis program informs the market expansion strategy",
  "metadata": {
    "priority": "high",
    "impactArea": "strategic",
    "frequency": "quarterly",
    "strength": 4
  }
}

Innovation and Transformation Relationships

These relationships capture how change and innovation propagate across the enterprise.

Relationship	Description	Example
innovates	Drives innovation or new developments in the target	Innovation innovates Capability
evolves	Causes evolutionary change in the target	Initiative evolves Technology
transforms	Drives transformational change in the target	Initiative transforms Value Stream
designs	Shapes the structure, approach or architecture of the target	Innovation designs Product
implements	Executes or realizes the vision, strategy or design of the target	Initiative implements Technology

{
  "relationshipID": "CDR-006",
  "sourceDomain": "initiative",
  "targetDomain": "valueStream",
  "relationshipType": "transforms",
  "description": "Digital transformation initiative fundamentally changes customer experience value streams",
  "metadata": {
    "priority": "critical",
    "impactArea": "customer",
    "strength": 5
  }
}

Coordination and Integration Relationships

These relationships describe how domains are synchronized and integrated for coherent operation.

Relationship	Description	Example
orchestrates	Coordinates the target's activities alongside other entities	Strategy orchestrates Initiatives
integrates	Brings together outputs or processes from the target	Technology integrates Information
synchronizes	Ensures timing alignment with the target	Value Stream synchronizes with Supply Chain
aligns	Is intentionally harmonized with the target in purpose, direction or design, without a direct dependency	Initiative aligns with Strategy
prioritizes	Influences the priority or sequencing of the target	Strategy prioritizes Initiatives

{
  "relationshipID": "CDR-012",
  "sourceDomain": "strategy",
  "sourceEntityID": "STR-GRW-2025",
  "targetDomain": "initiative",
  "targetEntityID": "INI-NME-001",
  "relationshipType": "prioritizes",
  "description": "The 2025 growth strategy ranks new market entry first among market-expansion initiatives",
  "metadata": {
    "priority": "strategic",
    "impactArea": "strategic",
    "frequency": "annually",
    "strength": 5
  }
}

Market and Demand Relationships

These relationships capture how market forces and demand patterns influence domains.

Relationship	Description	Example
drives	Generates, influences or amplifies demand for the target's outputs, services or capabilities	Market drives Product development
responds	Is triggered, adapted or activated in response to changes in the target or an external event	Value Stream responds to Customer

{
  "relationshipID": "CDR-013",
  "sourceDomain": "market",
  "sourceEntityID": "MKT-ENT-001",
  "targetDomain": "product",
  "targetEntityID": "PRD-ENT-001",
  "relationshipType": "drives",
  "description": "Strong digital-transformation demand in the enterprise segment drives development of the enterprise platform",
  "metadata": {
    "priority": "high",
    "impactArea": "customer",
    "strength": 4
  }
}

Complete Relationship Reference

The full set of 37 cross-domain relationship types (relationshipType), in schema order:

Category	Relationships
Financial	funds, measures, reports, forecasts
Operational	depends, constrains, enables, mitigates, consumes, delivers, optimizes, maintains
Governance	monitors, governs, audits, certifies, escalates, accountableFor, responsibleFor
Information and knowledge	informs, validates, enriches, learns, teaches, benchmarks
Innovation and transformation	innovates, evolves, transforms, designs, implements
Coordination and integration	orchestrates, integrates, synchronizes, aligns, prioritizes
Market and demand	drives, responds

Schema Reference

Cross-Domain Relationship

Attribute	Type	Required	Description
relationshipID	String	✓	Unique identifier for the relationship, e.g. CDR-001
sourceDomain	Enum	✓	The domain that initiates or provides in the relationship. Any domain except information, performance, product and service
sourceEntityID	String		ID of the source entity, when the relationship is between specific records
targetDomain	Enum	✓	The domain that receives the relationship
targetEntityID	String		ID of the target entity, when the relationship is between specific records
relationshipType	Enum	✓	How the source relates to the target; one of the 37 types above
description	String	✓	How the source and target interact
metadata	Object		Priority, impact area, frequency, strength, conditions and dates (see below)

Relationship Metadata (relationshipMetadata)

Attribute	Type	Required	Description
priority	Enum		Priority of the relationship
impactArea	Enum		Area of the organization the relationship affects
frequency	Enum		How often the relationship is exercised
strength	Integer		Strength of the relationship, 1 to 5
conditions	String		Conditions under which the relationship exists
effectiveDate	Date		Date the relationship becomes effective
reviewDate	Date		Date the relationship should be reviewed

Domains (targetDomain)

sourceDomain and targetDomain use the shared domain list. Every domain can be a target; the four passive domains cannot be a source.

Value	Description	Can be source
organization	Organization and its organization units	✓
stakeholder	Stakeholders and their requirements	✓
capability	Business capabilities	✓
strategy	Strategies and strategic objectives	✓
product	Products
service	Services
information	Information concepts and data
performance	Performance measures and KPIs
initiative	Initiatives, programs and projects	✓
policy	Policies, rules and controls	✓
valueStream	Value streams and their stages	✓
customer	Customers and segments	✓
market	Markets and market segments	✓
finance	Finance: budgets, funding and financial resources	✓
risk	Risk management	✓
modelRisk	Model risk management	✓
supplyChain	Supply chain	✓
innovation	Innovation	✓
sustainability	Sustainability	✓
people	People and workforce	✓
technology	Technology components and platforms	✓
channel	Channels	✓
socialChange	Social change	✓
intelligence	Intelligence	✓
manufacturing	Manufacturing	✓
businessAnalysis	Business analysis	✓
externalOrganization	External organizations	✓
trigger	Strategic Response Model triggers	✓
rationale	Strategic Response Model rationales	✓
strategicIntent	Strategic Response Model strategic intents	✓
strategicResponse	Strategic Response Model strategic responses	✓
obligation	Semantic Library obligations	✓
semanticConstraint	Semantic Library constraints on AI output	✓
complianceRequirement	Compliance requirements	✓
statementOfCompliance	Statements of compliance	✓
publicReport	Public reports	✓
mandatoryDisclosure	Mandatory disclosures	✓
useCase	Standardised AI use cases	✓
dataFlow	Dynamic and Time-Series data flows	✓
timeboundMetric	Dynamic and Time-Series timebound metrics	✓
predictiveModel	Dynamic and Time-Series predictive models	✓
other	A domain not listed here	✓

Priority (priority)

The shared priority list plus strategic.

Value	Description
low	Minor; address when convenient
medium	Notable; address in normal planning
high	Significant; address promptly
critical	Essential; failure would severely affect the target
strategic	Long-term strategic importance; prioritize in strategic planning

Impact Area (impactArea)

impactArea names the area of the organization the relationship affects, not a magnitude (use strength for that).

Value	Description
strategic	Strategic direction and positioning
operational	Day-to-day operations
tactical	Short- to medium-term plans and execution
financial	Costs, revenue and financial performance
regulatory	Compliance and regulatory obligations
customer	Customer experience and outcomes
innovation	Innovation and new development
risk	Risk exposure and mitigation

Frequency (frequency)

The shared frequency list.

Value	Description
continuous	Always running
realTime	Responds as events occur
hourly	Every hour
daily	Every day
weekly	Every week
monthly	Every month
quarterly	Every quarter
semiAnnually	Twice a year
annually	Once a year
eventDriven	Triggered by a defined event
onDemand	When requested
adHoc	Irregular, as needed

Relationship Strength (strength)

metadata.strength is an integer from 1 to 5 indicating the criticality of the connection:

Strength	Description
1	Very weak; minimal or optional connection
2	Weak; alternatives readily available
3	Moderate; notable connection but alternatives exist
4	Strong; significant dependency with material impact
5	Very strong; critical dependency, failure would severely impact the target

Relationships required by policy, regulation or contract are recorded with relationshipType governs or constrains and, where useful, the obligation in conditions.

Relationships on Domain Records

A domain record can list its own relationships in crossDomainRelationships. Each entry is an outgoing relationship (outgoingRelationship): the record that contains it is the source, so the entry names only the target. Domain schemas with crossDomainRelationships include technology, customer, channel, people, innovation, sustainability, risk management and model risk management.

Outgoing Relationship (outgoingRelationship)

Attribute	Type	Required	Description
targetDomain	Enum	✓	The domain that receives the relationship
targetEntityID	String		ID of the target entity, when the relationship is between specific records
relationshipType	Enum	✓	How the containing record relates to the target
description	String	✓	How the source and target interact
metadata	Object		Relationship metadata, as above

{
  "targetDomain": "capability",
  "targetEntityID": "CAP-INT-001",
  "relationshipType": "enables",
  "description": "Enables System Integration capability through standardized API management",
  "metadata": {
    "strength": 5
  }
}

Within a technology record, the list looks like this:

{
  "crossDomainRelationships": [
    {
      "targetDomain": "capability",
      "targetEntityID": "CAP-INT-001",
      "relationshipType": "enables",
      "description": "Enables System Integration capability through standardized API management",
      "metadata": { "strength": 5 }
    },
    {
      "targetDomain": "service",
      "targetEntityID": "SRV-PARTNER-002",
      "relationshipType": "delivers",
      "description": "Delivers secure partner integration services through managed APIs",
      "metadata": { "strength": 4 }
    }
  ]
}

Usage Guidelines

When to Use Cross-Domain Relationships

• Strategic planning — Map how strategic objectives cascade to capabilities and initiatives
• Impact assessment — Before changing a domain entity, trace its relationships
• Compliance mapping — Connect policies to the domains they govern
• Investment decisions — Understand what capabilities depend on proposed changes

Modeling Best Practices

1. Be specific — Use the most precise relationship type available
2. Document the "why" — Include descriptions explaining the relationship's purpose
3. Assess strength consistently — Apply the same criteria across the organization
4. Review periodically — Relationships change as the organization evolves; record a reviewDate
5. Start with critical paths — Model the most important relationships first

For Data Engineers

Cross-domain relationships map well to lineage and dependency tracking in data catalogs. When integrating with OpenMetadata, these relationships can populate the lineage graph, enabling impact analysis across business and technical domains.

Related Documentation

• Inter-Unit Relationships — Relationships between organizational units
• Relationship Directionality — Understanding relationship direction conventions
• Strategic Response Model — How triggers and responses use relationships