Relationship Directionality

Relationship directionality defines which entity is the source (initiator) and which is the target (recipient) in Orthogramic relationships. Consistent directionality is essential for accurate impact analysis, dependency tracking, and generating meaningful visualizations.

Schema Version: 2.1
Specification: JSON Schema Draft-07

Overview

Why Directionality Matters

In complex enterprise models, understanding the direction of relationships is critical:

• Impact analysis — "What depends on this?" vs "What does this depend on?"
• Change management — Trace downstream effects before making changes
• Governance — Identify who governs whom, not just that governance exists
• Visualization — Arrows in diagrams must point the right way to convey meaning

The Fundamental Principle

Relationships follow the direction of influence, action, or flow:

Source Entity  ──[relationship verb]──▶  Target Entity
     ↑                                        ↑
  Initiator                               Recipient
  Actor                                   Acted-upon
  Provider                                Receiver

The source is the entity that:

• Performs the action described by the relationship verb
• Initiates the influence or dependency
• Provides something to another entity

The target is the entity that:

• Receives the action
• Is influenced or dependent
• Receives something from the source

Cross-Domain Relationship Direction

For cross-domain relationships, the relationship verb indicates the direction:

Financial Relationships

Relationship	Source → Target	Example
funds	Finance → Initiative	Budget allocation flows TO the initiative
measures	Finance → Capability	Measurement is APPLIED TO the capability
reports	Finance → Value Stream	Reporting is ABOUT the value stream
forecasts	Finance → Initiative	Forecast is MADE FOR the initiative

Operational Relationships

Relationship	Source → Target	Interpretation
depends	A → B	A requires B to function
enables	A → B	A makes B possible
constrains	A → B	A limits B's operation
consumes	A → B	A uses outputs from B
delivers	A → B	A provides outputs to B

Inverse Relationships

enables and depends are inverses. If "Technology enables Capability" then "Capability depends on Technology." Model only one direction to avoid redundancy.

Governance Relationships

Relationship	Source → Target	Interpretation
governs	Policy → Capability	Policy exercises control OVER capability
monitors	Performance → Value Stream	Performance tracking is APPLIED TO value stream
audits	Risk Mgmt → Process	Audit is PERFORMED ON process
accountableFor	Stakeholder → Initiative	Stakeholder bears accountability FOR initiative

Innovation and Transformation

Relationship	Source → Target	Interpretation
transforms	Initiative → Value Stream	Initiative changes the value stream
innovates	Innovation → Capability	Innovation creates new capability
evolves	Initiative → Technology	Initiative causes technology to change

Inter-Unit Relationship Direction

For inter-unit relationships, direction depends on whether the unit is acting on or being affected by the domain entity:

Unit Acts ON Entity

Relationship	Direction	Meaning
owning	Unit → Entity	Unit has control over entity
providing	Unit → Entity	Unit supplies the entity
custodian	Unit → Entity	Unit stewards the entity
governing	Unit → Entity	Unit controls the entity
supporting	Unit → Entity	Unit assists with the entity

Unit Receives FROM Entity

Relationship	Direction	Meaning
consuming	Unit ← Entity	Unit uses the entity
benefiting	Unit ← Entity	Unit gains value from entity
dependent	Unit ← Entity	Unit's ops depend on entity

Modeling Conventions

Convention 1: Active Voice Verbs

Relationship types use active voice verbs where the source performs the action:

✅ Correct	❌ Avoid	Reason
funds	fundedBy	Active voice; source performs action
enables	enabledBy	Active voice
governs	governedBy	Active voice

Convention 2: One Direction Only

Model each relationship once in the primary direction. Avoid redundant inverse relationships:

// ✅ CORRECT - Model one direction
{
  "source": "capability-a",
  "target": "technology-b",
  "relationshipType": "depends"
}

// ❌ AVOID - Redundant inverse
{
  "source": "technology-b",
  "target": "capability-a",
  "relationshipType": "supports"  // This is just 'depends' reversed
}

Convention 3: Direction Follows the Question

Choose direction based on the question you're answering:

Question	Direction	Example
"What does X need?"	X → dependencies	Capability depends on Technology
"What enables X?"	enabler → X	Technology enables Capability
"What does X produce?"	X → outputs	Value Stream delivers to Customer
"What controls X?"	controller → X	Policy governs Capability

Convention 4: Consistent Direction Within Relationship Type

All instances of the same relationship type should follow the same directional convention:

// ✅ CONSISTENT - All 'funds' relationships flow from Finance
{"source": "finance", "target": "initiative-a", "relationshipType": "funds"}
{"source": "finance", "target": "initiative-b", "relationshipType": "funds"}
{"source": "finance", "target": "capability-x", "relationshipType": "funds"}

// ❌ INCONSISTENT - Mixed directions for same relationship type
{"source": "finance", "target": "initiative-a", "relationshipType": "funds"}
{"source": "initiative-b", "target": "finance", "relationshipType": "funds"}  // Wrong!

Direction Reference Table

Cross-Domain Relationships

Type	Source	Target	Mnemonic
funds	Funder	Funded	Money flows to
measures	Measurer	Measured	Metrics applied to
depends	Dependent	Dependency	I need you
enables	Enabler	Enabled	I make you possible
constrains	Constraint	Constrained	I limit you
governs	Governor	Governed	I control you
informs	Informer	Informed	Information flows to
transforms	Transformer	Transformed	I change you
consumes	Consumer	Consumed	I use your output
delivers	Deliverer	Delivered-to	I give to you

Inter-Unit Relationships

Type	Source	Target	Flow
owning	Unit	Entity	Unit → Entity
providing	Unit	Entity	Unit → Entity
consuming	Entity	Unit	Entity → Unit
custodian	Unit	Entity	Unit → Entity
governing	Unit	Entity	Unit → Entity
dependent	Entity	Unit	Entity → Unit

Visualization Implications

When generating diagrams from relationship data:

1. Arrow direction — Arrows point from source to target
2. Label placement — Relationship verb labels the arrow
3. Color coding — Consider coloring by relationship category
4. Layout — Sources typically on left, targets on right for left-to-right flow

Querying by Direction

When building queries against the metamodel, direction determines the traversal path:

Downstream Impact (What does this affect?)

-- Find all entities affected by changing capability-x
SELECT target_entity, relationship_type
FROM cross_domain_relationships
WHERE source_entity = 'capability-x';

Upstream Dependencies (What does this need?)

-- Find all dependencies of capability-x
SELECT source_entity, relationship_type
FROM cross_domain_relationships
WHERE target_entity = 'capability-x'
  AND relationship_type = 'depends';

Full Dependency Graph

-- Recursive query for full dependency tree
WITH RECURSIVE dep_tree AS (
  SELECT source_entity, target_entity, relationship_type, 1 as depth
  FROM cross_domain_relationships
  WHERE source_entity = 'capability-x'
  
  UNION ALL
  
  SELECT r.source_entity, r.target_entity, r.relationship_type, dt.depth + 1
  FROM cross_domain_relationships r
  JOIN dep_tree dt ON r.source_entity = dt.target_entity
  WHERE dt.depth < 5
)
SELECT * FROM dep_tree;

Common Mistakes

Mistake	Problem	Correction
Reversing depends	"Technology depends on Capability"	Capability depends on Technology
Bidirectional modeling	Creating both enables and depends	Choose one direction
Passive voice types	Using fundedBy instead of funds	Use active voice
Inconsistent direction	Same type pointing both ways	Standardize direction

Related Documentation

• Cross-Domain Relationships — Full list of cross-domain relationship types
• Inter-Unit Relationships — Organizational unit relationship types
• Strategic Response Model — How triggers chain through relationships