CR-6 — Temporal, Lifecycle & Transition Semantics
| Field | Value |
|---|---|
| Status | Implemented (v0.11.0) |
| Depends on | CR-1 through CR-5 |
| Primary objective: Give OpenDEA a rigorous model of time, state, lifecycle, transition, version, validity, and target architecture, so that the metamodel can represent not merely what exists, but what existed, what exists now, what is planned, what is changing, what is intended, and what actually became true. |
CR-5 established:
Architecture → Assessment → Gap → Change → Target
CR-6 now establishes the temporal semantics that make that chain operational.
The central principle is:
Architecture is a time-dependent state of an enterprise, not a static catalogue of entities.
⸻
- The problem CR-6 must solve
Without explicit temporal semantics, a model tends to collapse these fundamentally different statements:
Application A exists. Application A existed in 2024. Application A is planned for 2027. Application A is being replaced. Application A was scheduled for retirement. Application A was actually retired. Application A is valid only for Business Unit X. Application A has been superseded by Application B.
These are not equivalent.
OpenDEA needs to distinguish:
EXISTENCE VALIDITY VERSION STATE LIFECYCLE CHANGE TRANSITION INTENTION REALIZATION
⸻
- The target temporal model
The conceptual model should become:
ENTERPRISE
│
↓
Architecture
│
┌────────────┼────────────┐
↓ ↓ ↓
Baseline Current Target
│ │ │
└────────────┼────────────┘
↓
Transition
│
┌────────────┼────────────┐
↓ ↓ ↓
Planned Active Completed
Change Change Change
│ │ │
└────────────┼────────────┘
↓
Future State
But planned state must never be treated as actual architecture.
That distinction is critical.
⸻
- CR-6A — Introduce temporal semantics
Create:
/metamodel/profiles/lifecycle/ lifecycle.yaml temporal.yaml states.yaml transitions.yaml constraints.yaml
The temporal model should introduce:
TemporalEntity TemporalInterval TemporalEvent TemporalState LifecycleState Transition
⸻
- TemporalEntity
Do not duplicate temporal attributes across every entity.
Instead, define a reusable temporal pattern.
Conceptually:
temporal: valid_from: valid_to: observed_at: created_at: retired_at:
But these dates have different semantics and should not be treated as interchangeable.
⸻
- Distinguish the different clocks
This is one of the most important parts of CR-6.
OpenDEA should distinguish at least:
Transaction time
When the model knows something.
recorded_at updated_at
Valid time
When something is true in the enterprise.
valid_from valid_to
Observation time
When something was observed.
observed_at
Planned time
When something is expected to happen.
planned_start planned_end
Effective time
When a decision/change becomes effective.
effective_from effective_to
This distinction prevents serious temporal ambiguity.
⸻
- Example
Suppose an application is retired on January 1, 2027.
The enterprise may know this in August 2026.
Therefore:
recorded_at = 2026-08-17 planned_retirement = 2027-01-01 valid_to = 2027-01-01
These represent different facts.
Do not collapse them into:
retirement_date = 2027-01-01
⸻
- CR-6B — Lifecycle semantics
Every lifecycle-aware entity should be capable of moving through explicit states.
Generic lifecycle:
Concept ↓ Proposed ↓ Approved ↓ Planned ↓ Active ↓ Deprecated ↓ Retired
But this should not be blindly applied to every entity.
Instead:
Lifecycle state must be defined by the entity type or profile.
For example:
Application
Proposed Approved Under Development Testing Active Deprecated Retired
Capability
Identified Established Evolving Retired
Change
Proposed Approved In Progress Completed Cancelled
⸻
- LifecycleState vs AssessmentState
Do not confuse:
Lifecycle State
with:
Maturity Level
For example:
Application A Lifecycle = Active Capability A Maturity = Level 3
These describe different dimensions.
Likewise:
Change A Lifecycle = In Progress Assessment A Status = Completed
Again, different semantics.
⸻
- CR-6C — State as a first-class architectural concept
Introduce:
ArchitectureState
An ArchitectureState is a coherent representation of the enterprise architecture at a defined temporal point or condition.
Examples:
Current State Baseline State Target State Transition State Scenario State
The model should therefore support:
ArchitectureState │ ├── contains → ArchitectureElement ├── valid-during → TemporalInterval └── characterized-by → StateCondition
⸻
- Baseline State
A baseline is an explicitly captured state of the enterprise architecture.
For example:
Baseline 2026
It should identify:
state_id captured_at valid_at scope source
The key point:
A baseline is not simply “whatever the current model happens to contain.”
It is a declared architectural snapshot.
⸻
- Current State
Current state should represent the best authoritative representation of what exists at a specified time.
Current State │ ├── actual architecture ├── actual relationships └── actual lifecycle states
It must not automatically include:
planned proposed target hypothetical
elements.
⸻
- Target State
Target architecture should be explicitly represented:
TargetArchitecture │ └── target-state → ArchitectureState
It represents an intended future condition.
Therefore:
Target ≠ Current Target ≠ Planned Change Target ≠ Forecast
These distinctions are essential.
⸻
- CR-6D — Transition State
Most real enterprise transformation does not jump:
Current → Target
Instead:
Current ↓ Transition 1 ↓ Transition 2 ↓ Transition 3 ↓ Target
Introduce:
TransitionState
Example:
Current Architecture ↓ ERP migration phase 1 ↓ Hybrid ERP architecture ↓ ERP migration phase 2 ↓ Target ERP architecture
⸻
- Transition
A Transition represents the movement between architecture states.
Transition │ ├── from-state ├── to-state ├── caused-by → Change ├── starts ├── ends └── status
Example:
transition: id: TR-2026-004 from_state: baseline-2026 to_state: transition-2027 change: change-erp-modernization planned_start: 2026-09-01 planned_end: 2027-06-30
⸻
- CR-6E — Change semantics
CR-5 introduced Change.
CR-6 now formalizes it.
A Change should describe:
what changes why it changes when it changes who authorizes it what state it creates what state it replaces
Relationships:
Change │ ├── affects → ArchitectureElement ├── replaces → ArchitectureElement ├── introduces → ArchitectureElement ├── removes → ArchitectureElement ├── modifies → ArchitectureElement ├── realizes → TargetState └── results-in → Outcome
⸻
- Planned vs Actual Change
This distinction is mandatory.
Planned Change
means:
The enterprise intends to perform the change.
Actual Change
means:
The change has actually occurred.
For example:
Planned: Retire Application A on 2027-01-01. Actual: Application A was retired on 2027-03-15.
The model must support both.
⸻
- Don’t overwrite history
This should become an explicit repository rule.
Bad:
Application A status = Retired
with no indication that it was previously Active.
Better:
Application A Active valid: 2024-01-01 → 2027-03-15 Retired effective: 2027-03-15
The model should preserve architectural history.
⸻
- CR-6F — Versioning
Versioning must be separated from lifecycle.
For example:
Application CRM v1.0 v1.1 v2.0
does not mean:
v1.0 → deprecated v1.1 → deprecated v2.0 → active
necessarily.
Version represents identity evolution.
Lifecycle represents operational state.
Temporal validity represents when the state applies.
These are three different concepts.
⸻
- Version semantics
Introduce:
Version VersionedEntity VersionRelation
Relationships:
Version ├── predecessor → Version └── successor → Version
Example:
CRM │ ├── v1.0 ├── v1.1 └── v2.0
⸻
- Supersession
Supersession is not identical to versioning.
For example:
Application A ↓ superseded-by ↓ Application B
A and B may be completely different products.
Therefore:
version-of
and:
superseded-by
must remain distinct relationships.
⸻
- CR-6G — Temporal relationship semantics
Relationships themselves can change over time.
This is a major issue that should be explicitly addressed.
Example:
Application A ──supports──> Capability X
may be true from 2024–2027.
Then:
Application B ──supports──> Capability X
from 2027 onward.
Therefore relationships need temporal validity.
Conceptually:
relationship: type: supports source: application-a target: capability-x valid_from: 2024-01-01 valid_to: 2027-03-15
This is essential for historical architecture queries.
⸻
- Relationship State
A relationship can also be:
Proposed Planned Active Deprecated Retired
Example:
Application B ──planned-supports──> Capability X
must not be interpreted by the viewer as:
Application B ──supports──> Capability X
today.
This distinction should be enforced at the metamodel level.
⸻
- CR-6H — Effective architecture
Introduce a concept of:
EffectiveArchitecture
which is a derived view of the model at a particular point in time.
For example:
getArchitecture(asOf = 2026-08-17)
should return:
all entities valid at 2026-08-17 + all relationships valid at 2026-08-17 + appropriate lifecycle states
Likewise:
getArchitecture(asOf = 2028-01-01)
can produce a future planned/target view according to declared semantics.
⸻
- This should change the viewer
The viewer should eventually support:
TIME 2024 ───── 2025 ───── 2026 ───── 2027 ───── 2028 │ ▼ [Current State]
and:
View: ● Current ● Baseline ● Target ● Planned ● Scenario ● Historical
The visual layer should derive these views from the semantic model.
⸻
- CR-6I — Scenario semantics
A scenario is different from a target.
Introduce:
Scenario ScenarioState ScenarioAssumption
Example:
Scenario A: Cloud-first Scenario B: Hybrid Scenario C: On-premise modernization
A scenario is:
A hypothetical architecture state under a defined set of assumptions.
It is not necessarily the approved target.
⸻
- Scenario isolation
Scenario entities should not accidentally become part of the authoritative architecture.
Therefore:
Scenario │ └── contains → ScenarioState
rather than inserting hypothetical elements directly into:
CurrentArchitecture
⸻
- CR-6J — Forecast vs Target
These must also be distinct.
Forecast
What is expected to happen.
Target
What the organization intends to achieve.
For example:
Forecast maturity = 3.4 Target maturity = 4.0
The forecast may fail to reach the target.
This becomes especially useful when combined with CR-5:
Current = 2.7 Target = 4.0 Forecast = 3.5
The model can then expose a forecast-to-target gap.
⸻
- CR-6K — Lifecycle events
Introduce:
LifecycleEvent
Examples:
Created Approved Activated Modified Suspended Deprecated Retired Reactivated Superseded
An event should capture:
event subject timestamp actor reason source
Example:
event: type: retired subject: application-a occurred_at: 2027-03-15 actor: architecture-board reason: replacement by application-b
This creates an auditable lifecycle history.
⸻
- Event vs State
Do not confuse:
Event
with:
State
An event is something that happened.
A state is the condition resulting from events.
Retirement Event ↓ Application State = Retired
This distinction will become increasingly important for agentic architecture later.
⸻
- CR-6L — Architecture snapshots
Introduce:
ArchitectureSnapshot
A snapshot should capture:
snapshot_id scope captured_at valid_at model_version source
Example:
Enterprise Architecture Snapshot 2026-Q3
This is useful for:
- audits;
- regulatory reporting;
- maturity assessments;
- historical comparison;
- transformation governance.
⸻
- Snapshot vs Baseline
A snapshot is simply a captured representation.
A baseline is a formally adopted reference state.
Therefore:
Snapshot │ └── may-become → Baseline
but:
Snapshot ≠ Baseline
⸻
- CR-6M — Architecture delta
Introduce:
ArchitectureDelta
A delta represents the semantic difference between two states.
For example:
Baseline 2026 ↓ DELTA ↓ Target 2028
The delta can contain:
Added Removed Modified Replaced Reclassified Relationship changes
Example:
delta: from: baseline-2026 to: target-2028 changes: - type: added entity: application-b - type: retired entity: application-a - type: relationship-added relationship: application-b-supports-capability-x
⸻
- Architecture Delta is extremely important
This gives OpenDEA a native mechanism for:
“What must change to move from here to there?”
which is precisely the bridge between:
- DMM;
- target architecture;
- transformation;
- roadmaps.
It also allows the viewer to visualize:
Current │ ├── green = retained ├── blue = modified ├── violet = added └── red = removed │ ↓ Target
The exact visual language belongs to the viewer, not the ontology.
⸻
- CR-6N — Dependency-aware transition
A Change may depend on another Change.
Example:
Change A: Establish data platform ↓ enables Change B: Deploy AI customer service agents ↓ enables Change C: Automate customer service process
Therefore:
Change ──depends-on──> Change
and:
Change ──enables──> Change
should be supported.
This should reuse the relationship semantics established in CR-2.
⸻
- Transition constraints
The metamodel should support transition constraints such as:
Change B cannot start until Change A is complete.
or:
Application B cannot become active until Application A is retired.
or:
Capability X must reach maturity ≥ 3 before AI Agent Y is deployed.
These should be represented as constraints/rules rather than hard-coded application logic.
⸻
- CR-6O — Temporal integrity rules
Introduce automated conformance rules.
T001 — No invalid intervals
valid_from < valid_to
T002 — No impossible lifecycle
An entity cannot become:
Retired → Active
unless explicitly supported by a reactivation transition.
T003 — No future entity in current state
A planned element cannot appear in the authoritative current architecture.
T004 — Temporal relationship integrity
A relationship cannot be active outside the validity of its endpoints where the relationship semantics require endpoint existence.
T005 — No contradictory lifecycle states
An entity cannot simultaneously be:
Active Retired
for the same scope and time.
T006 — Target separation
Target-state entities must not be interpreted as current-state entities.
T007 — Scenario isolation
Scenario entities cannot silently contaminate the authoritative architecture.
T008 — Version ordering
Version relationships must be acyclic.
T009 — Supersession consistency
A superseded entity must have a valid successor where the relationship semantics require one.
T010 — Historical immutability
Approved historical snapshots should not be mutated without explicit revision semantics.
⸻
- CR-6P — Temporal query semantics
The repository should define canonical query operations.
For example:
getCurrentArchitecture(scope) getArchitectureAt(time, scope) getBaseline(id) getTarget(id) getTransitionState(id) getArchitectureDelta(from, to) getLifecycleHistory(entity) getChangesAffecting(entity) getPlannedChanges(period) getActualChanges(period)
These are not necessarily ontology entities; they are model services/query semantics.
⸻
- CR-6Q — Example
Consider:
Capability: Customer Service
2025
Application A supports Customer Service
2026
Application A supports Customer Service Application B planned-supports Customer Service
2027
Application A retired Application B supports Customer Service
OpenDEA should be able to answer:
What supported Customer Service in 2025?
→ Application A
What supports it today?
→ Application A
What is planned to support it?
→ Application B
What supported it after the transition?
→ Application B
This is the practical test of CR-6.
⸻
- CR-6R — Assessment temporal integration
CR-5 results must connect cleanly to CR-6.
For example:
DMM Assessment 2026 │ ↓ Current Maturity = 2.7 │ ↓ Target Maturity = 4.0 │ ↓ Target Date = 2028
Then:
2026 ───── 2027 ───── 2028 │ │ │ 2.7 3.4 4.0 │ │ │ Current Transition Target
The metamodel should support reassessment:
2027 Assessment
which can determine whether the transformation is actually progressing toward the target.
⸻
- CR-6S — DMM temporal model
DMM should therefore become capable of showing:
DMM MATURITY
│
┌─────────────┼─────────────┐
↓ ↓ ↓
Baseline Current Target
│ │ │
2.1 2.7 4.0
│ │ │
└─────────────┼─────────────┘
↓
Transformation
│
↓
Reassessment
│
↓
3.4 actual
This gives DMM a genuine dynamic maturity trajectory.
⸻
- CR-6T — Repository implementation
Recommended structure:
/metamodel/ │ ├── core/ │ ├── profiles/ │ ├── assessment/ │ ├── dmm/ │ └── lifecycle/ │ ├── states/ │ ├── baseline/ │ ├── current/ │ ├── target/ │ └── scenarios/ │ ├── migrations/ │ └── validation/ ├── temporal/ ├── lifecycle/ └── transition/
If the repository already has an alternative structure, preserve its conventions; the semantic separation is more important than these exact directories.
⸻
- CR-6 implementation sequence
Phase 1 — Temporal vocabulary
Define:
TemporalInterval ValidTime TransactionTime ObservedTime PlannedTime EffectiveTime
⸻
Phase 2 — Lifecycle
Define:
LifecycleState LifecycleEvent LifecycleTransition
⸻
Phase 3 — Architecture states
Implement:
ArchitectureState Baseline Current Target Transition Scenario
⸻
Phase 4 — Change
Formalize:
Change ChangeStatus ChangeDependency ChangeEffect
⸻
Phase 5 — Temporal relationships
Allow relationships to have validity where necessary.
⸻
Phase 6 — Snapshots and deltas
Implement:
ArchitectureSnapshot ArchitectureDelta
⸻
Phase 7 — Assessment integration
Connect:
AssessmentResult ↓ ArchitectureState ↓ Change ↓ TargetState
⸻
Phase 8 — Validation
Implement the temporal and lifecycle conformance suite.
⸻
Phase 9 — Viewer
Introduce:
Timeline State selector Baseline/Target comparison Change overlay Architecture delta Historical playback
⸻
- CR-6 acceptance criteria
CR-6 should not be considered complete until:
- Temporal semantics are formally defined.
- Valid time is separated from transaction time.
- Planned time is separated from actual/effective time.
- Lifecycle state is distinct from maturity level.
- ArchitectureState exists as a first-class concept.
- Baseline State is explicitly representable.
- Current State is explicitly representable.
- Target State is explicitly representable.
- Transition State is explicitly representable.
- Scenario State is explicitly representable.
- Change has explicit lifecycle semantics.
- Planned and actual change are distinguishable.
- Relationships can be temporally bounded where necessary.
- Lifecycle events are captured.
- Version is distinct from lifecycle.
- Version is distinct from supersession.
- Architecture snapshots are supported.
- Baselines are distinguishable from snapshots.
- Architecture deltas are derivable.
- Change dependencies are representable.
- Temporal integrity rules are automated.
- Historical states are reproducible.
- Future target states cannot contaminate current-state queries.
- Scenario states cannot contaminate authoritative architecture.
- DMM assessments can be associated with specific architectural states.
- Current → Target → Transition semantics are supported.
- Viewer can navigate architecture through time.
⸻
- Definition of Done
The decisive test is whether OpenDEA can answer these questions without ambiguity:
What did the enterprise architecture look like on January 1, 2025?
What does it look like today?
What has been approved but not yet implemented?
What is the intended target architecture in 2028?
What changes are required to get there?
Which changes are currently underway?
Which changes actually happened?
Which DMM assessment established the baseline?
Has the enterprise’s maturity actually improved since that baseline?
What architecture elements changed between the baseline and target?
If the model can answer those questions from its semantic graph rather than from undocumented application logic, CR-6 has succeeded.
⸻
- The resulting DEA architecture
After CR-6, the conceptual stack becomes:
OPENDEA
│
┌───────────────────┼───────────────────┐
│ │ │
↓ ↓ ↓
CORE ONTOLOGY ASSESSMENT LIFECYCLE │ │ │ │ │ │ ↓ ↓ ↓ Enterprise DMMv5 / Time Elements Frameworks State │ Measures Version │ Evidence Event │ Results Change │ Targets Transition │ │ │ └───────────────────┼───────────────────┘ ↓ TRANSFORMATION │ ┌─────────┴─────────┐ ↓ ↓ Current State Target State │ │ └────────┬──────────┘ ↓ Architecture Delta │ ↓ Change │ ↓ Outcome │ ↓ Reassessment
This gives OpenDEA a much stronger conceptual foundation:
Structure + Assessment + Time + Change.
⸻
- One important architectural decision for CR-7
At this point, I would not immediately introduce agents as just another set of entities.
CR-6 gives us the machinery needed for the next step.
CR-7 should establish Decision, Intent, Policy, Governance & Agentic Semantics, building on:
Actor Decision Information Capability Service Assessment Change State Transition
The key question CR-7 should answer is:
How does an enterprise architecture represent not only what exists and what changes, but who/what makes decisions, under what intent, policies, constraints, evidence and authority—and how autonomous agents participate in that architecture?
That is the point at which the DEA metamodel can begin to model the agentic enterprise, rather than merely adding an Agent entity to an otherwise conventional EA metamodel.