CR-9 — OpenDEA Runtime, Knowledge Graph & Interoperability Architecture
Status: Proposed Depends on: CR-1 → CR-8 Primary objective: Turn OpenDEA from a conformant semantic model into an executable enterprise semantic substrate capable of ingestion, graph construction, querying, reasoning, assessment, decision support, agent interaction, and continuous synchronization with enterprise systems.
CR-8 defined the language and rules. CR-9 defines the runtime that operates on that language.
⸻
- CR-9 strategic intent
The progression should now be:
CR-1 → CR-7 Semantic foundations ↓ CR-8 Specification + conformance ↓ CR-9 Runtime + knowledge graph + interoperability ↓ CR-10+ Intelligence, simulation, optimization and ecosystem
The key architectural proposition is:
OpenDEA should become a semantic operating layer for enterprise architecture, rather than another architecture repository.
The runtime therefore needs to support this continuous loop:
┌───────────────────────┐
│ Enterprise Reality │
│ │
│ Systems / People / │
│ Processes / Data / AI │
└──────────┬────────────┘
│
Ingest
↓
┌───────────────────────┐
│ OpenDEA Knowledge │
│ Graph │
└──────────┬────────────┘
│
┌───────────────┼────────────────┐
↓ ↓ ↓
Assess Reason Query
│ │ │
└───────────────┼────────────────┘
↓
Decision Support
↓
Action / Change
↓
Enterprise Reality
That closed loop is the central CR-9 architectural objective.
⸻
- CR-9A — Define the runtime architecture
Establish a formal runtime architecture:
┌──────────────────────────────────────────────────────────────┐ │ OPENDEA RUNTIME │ ├──────────────────────────────────────────────────────────────┤ │ API / Query / Agent Interface │ ├──────────────────────────────────────────────────────────────┤ │ Semantic Services │ │ Validation | Reasoning | Assessment | Decision | Inference │ ├──────────────────────────────────────────────────────────────┤ │ Knowledge Graph │ │ Entities | Relationships | Assertions | Provenance │ ├──────────────────────────────────────────────────────────────┤ │ Semantic Registry │ │ Core | Profiles | Schemas | Rules | Ontologies │ ├──────────────────────────────────────────────────────────────┤ │ Integration / Ingestion │ │ APIs | Events | Files | Databases | SaaS | Agents │ ├──────────────────────────────────────────────────────────────┤ │ Enterprise Systems │ └──────────────────────────────────────────────────────────────┘
Each layer should have a clear responsibility.
⸻
- CR-9B — Separate model from runtime state
This distinction is essential.
OpenDEA should distinguish:
Model
What the enterprise is understood to be.
Runtime state
What is currently observed.
Assertions
What someone or something claims.
Evidence
What supports that claim.
Derived knowledge
What the runtime infers.
Conceptually:
Model │ ├── Assertion │ └── Evidence │ ├── Observation │ └── Inference
Do not collapse these into a single entity representation.
⸻
- CR-9C — Knowledge graph as the runtime semantic backbone
The graph should represent:
Entities Relationships Properties Assertions Evidence Context Time Provenance Confidence State
A simplified graph:
Strategy
│
drives
↓
Objective
│
prioritizes
↓
Capability
/ \
realizedBy assessedBy
↓ ↓
Service Assessment
│ │
implementedBy measures
↓ ↓
Application Measure
│
deployedOn
↓
Technology
The graph is not merely a visualization structure.
It is the runtime semantic representation.
⸻
- CR-9D — Graph abstraction
Do not tie OpenDEA directly to one graph database.
Define a logical graph interface:
GraphStore ├── createEntity() ├── updateEntity() ├── deleteEntity() ├── createRelationship() ├── query() ├── traverse() ├── findPath() ├── infer() └── transaction()
Possible implementations can then include:
Neo4j Amazon Neptune ArangoDB PostgreSQL + graph extensions RDF triplestore In-memory graph
The runtime remains implementation-independent.
⸻
- CR-9E — Canonical graph model
Define:
Node Edge Property Assertion Context Source Evidence Observation Inference
An edge should itself be capable of carrying metadata.
For example:
relationship: type: supports source: capability.customer-service target: service.customer-support provenance: sourceSystem: architectureRepository assertedBy: architect-42 temporal: validFrom: 2026-01-01 confidence: 0.94
This is substantially more useful than a simple source → target graph.
⸻
- CR-9F — Temporal graph
CR-6 introduced lifecycle and time.
CR-9 must operationalize it.
The graph needs to answer:
What is true now?
and:
What was true last year?
and:
What is expected to become true next year?
Therefore relationships and assertions should support:
validFrom validTo observedAt createdAt supersededAt effectiveFrom effectiveTo
⸻
- CR-9G — Bitemporal semantics
Where practical, introduce bitemporal representation:
Valid Time + Transaction Time
Example:
Valid: 2026-01-01 → 2027-01-01 Recorded: 2026-08-18
This allows the system to distinguish:
“The architecture changed in January”
from:
“We only learned about the change in August.”
This is extremely valuable for enterprise governance and auditability.
⸻
- CR-9H — Event model
The runtime needs a first-class event mechanism.
Examples:
CapabilityChanged ApplicationDeployed PolicyChanged AssessmentCompleted AgentActivated DecisionApproved ServiceDegraded RiskDetected ArchitectureUpdated
Every event should contain:
event: id: type: timestamp: actor: subject: context: payload: source:
⸻
- CR-9I — Event-driven synchronization
The runtime should support:
Enterprise System ↓ Event ↓ OpenDEA Event Gateway ↓ Semantic Transformation ↓ Knowledge Graph ↓ Inference ↓ Updated Architecture State
This prevents the graph from becoming a static snapshot.
⸻
- CR-9J — Source adapters
Define an adapter architecture:
OpenDEA
↑
Semantic Integration
↑
┌──────────────┼───────────────┐
↓ ↓ ↓
API Database Events ↓ ↓ ↓ CRM CMDB Kafka ERP HRIS Webhooks ITSM Data Lake SaaS
Adapters should perform:
Extract Transform Map Validate Enrich Load
⸻
- CR-9K — Semantic mapping layer
Never allow every integration to directly manipulate the Core graph.
Use:
Source Schema ↓ Source Mapping ↓ OpenDEA Semantic Model ↓ Validation ↓ Graph
For example:
Salesforce.Account ↓ OpenDEA.Organization
and:
ServiceNow.CMDB_CI ↓ OpenDEA.TechnologyComponent
The mapping must be explicit and versioned.
⸻
- CR-9L — Mapping specification
Define a machine-readable mapping format.
Conceptually:
mapping: source: ServiceNow version: "1.0" mappings: - sourceType: cmdb_ci_server targetType: TechnologyNode properties: name: name serialNumber: externalId operationalStatus: state
This makes integrations reproducible.
⸻
- CR-9M — Identity resolution
CR-8 established identity.
CR-9 must operationalize it.
The runtime needs an identity-resolution service:
Source Object A │ ├── exact match ├── identifier match ├── semantic match └── probabilistic match ↓ OpenDEA Entity
Example:
CRM: Customer Support ITSM: Customer Support Service DMM: Customer Service Capability
The runtime must determine whether these are:
same entity related entities different entities unknown
Never automatically merge uncertain identities.
⸻
- CR-9N — Entity resolution confidence
Every non-deterministic identity resolution should record:
matchScore matchingMethod evidence reviewRequired approvedBy
Example:
identityResolution: candidate: service.customer-support score: 0.93 method: semantic+identifier status: proposed
This is especially important when AI performs entity matching.
⸻
- CR-9O — Assertion architecture
CR-9 should explicitly model:
Assertion │ ├── assertedBy ├── supportedBy ├── validDuring ├── confidence ├── status └── source
Possible statuses:
Proposed Verified Approved Rejected Superseded Disputed
This allows multiple competing assertions to coexist without corrupting the underlying graph.
⸻
- CR-9P — Evidence graph
Evidence should become a graph rather than a document attachment.
Assertion │ supportedBy ↓ Evidence │ derivedFrom ↓ Source
Example:
"Capability maturity = 2.7" │ supportedBy ↓ Assessment │ basedOn ↓ Assessment Evidence
This creates auditability.
⸻
- CR-9Q — Semantic reasoning engine
Introduce a reasoning service:
Graph ↓ Rules ↓ Inference ↓ Derived Assertions
Rules might include:
IF Capability supports Objective AND Objective is Strategic THEN Capability is StrategicCapability
Or:
IF Agent performs Action AND Action changes CustomerData AND Agent is autonomous THEN Agent requires DataGovernancePolicy
⸻
- CR-9R — Reasoning levels
Do not mix all reasoning together.
Define:
Level 1 — Deterministic
Explicit rules.
Level 2 — Ontological
Type/inheritance inference.
Level 3 — Graph
Path and dependency inference.
Level 4 — Probabilistic
Confidence-based inference.
Level 5 — Generative
LLM-assisted reasoning.
Deterministic ↓ Semantic ↓ Graph ↓ Probabilistic ↓ Generative
Every derived result must indicate its reasoning level.
⸻
- CR-9S — Rule registry
Rules become first-class runtime artifacts.
rule: id: DEA-GOV-001 name: AutonomousAgentRequiresAuthority appliesTo: - Agent condition: ... consequence: ... severity: error
Rules should be:
versioned enabled/disabled profile-scoped testable traceable
⸻
- CR-9T — Inference provenance
Never produce:
Capability X is strategic.
without being able to answer:
Why?
The runtime should return:
Inference: Capability X = Strategic Because:
- supports Objective Y
- Objective Y = Strategic
- rule DEA-INF-007 applied Confidence: 0.96
This is essential for AI-assisted enterprise architecture.
⸻
- CR-9U — Query service
Provide a semantic query layer above the underlying graph technology.
Queries should support:
entity lookup relationship lookup path traversal dependency analysis impact analysis temporal queries profile queries assessment queries governance queries
Example:
Find all applications supporting capabilities below maturity level 3.
Graph traversal:
Application → implements → Service → supports → Capability → assessedBy → Assessment → result < 3
⸻
- CR-9V — Natural-language query
Add an optional semantic query interface:
User: "Which critical capabilities are currently below maturity target and have no funded transformation initiative?"
Pipeline:
Natural Language ↓ Intent Extraction ↓ OpenDEA Semantic Query ↓ Graph Query ↓ Evidence ↓ Answer
Crucially:
The LLM should translate the question into OpenDEA semantics rather than directly querying arbitrary databases.
⸻
- CR-9W — Query explainability
Natural-language queries must return:
Question ↓ Interpreted concepts ↓ Graph traversal ↓ Filters ↓ Evidence ↓ Result
This prevents the architecture assistant from becoming a black box.
⸻
- CR-9X — Assessment engine
CR-5 becomes executable.
The runtime should support:
Assessment Definition ↓ Assessment Execution ↓ Evidence Collection ↓ Scoring ↓ Maturity Result ↓ Gap ↓ Recommendation
Assessment results become graph entities.
⸻
- CR-9Y — DMM runtime
For the DMM use case, the graph should be able to represent:
Enterprise ↓ Pillar ↓ Dimension ↓ Capability ↓ Assessment ↓ Current Maturity ↓ Target Maturity ↓ Gap ↓ Initiative
This gives the DMM a direct connection to architecture.
Instead of:
“Technology maturity is 2.8.”
the graph can answer:
“Which technology weaknesses are preventing strategic capabilities from reaching their target state?”
That is a much stronger proposition.
⸻
- CR-9Z — Impact analysis engine
A major runtime capability should be:
What happens if X changes?
For example:
Change: Retire Application A
The runtime determines:
Application ↓ Services ↓ Capabilities ↓ Objectives ↓ Customers ↓ Risks ↓ Agents ↓ Processes
Output:
Direct Impact Indirect Impact Risk Dependencies Affected Objectives Affected Agents Required Decisions
⸻
- CR-9AA — Dependency analysis
Support queries such as:
What depends on this application?
What does this capability depend on?
Which technology components create a single point of failure?
Which agents depend on this service?
The graph should calculate dependency paths.
⸻
- CR-9AB — Criticality propagation
Introduce propagation rules.
Example:
Strategic Objective ↓ Critical Capability ↓ Critical Service ↓ Critical Application ↓ Critical Technology
Criticality should be explicitly modeled rather than inferred purely from object type.
Possible levels:
Low Medium High Critical MissionCritical
⸻
- CR-9AC — Risk propagation
Similarly:
Risk ↓ Capability ↓ Service ↓ Application ↓ Technology
The runtime should support risk propagation and aggregation.
For example:
Technology vulnerability ↓ Application exposure ↓ Service degradation risk ↓ Capability risk ↓ Strategic objective risk
⸻
- CR-9AD — Decision engine
CR-7’s Decision becomes executable.
The runtime should represent:
Decision ├── Context ├── Alternatives ├── Criteria ├── Evidence ├── Constraints ├── Authority ├── DecisionMaker ├── Decision └── Consequence
The system should distinguish:
Decision support
from:
Decision execution
The latter requires explicit authorization.
⸻
- CR-9AE — Decision lifecycle
Implement:
Proposed ↓ UnderReview ↓ Approved ↓ Executed ↓ Observed ↓ Evaluated ↓ Closed
And potentially:
Rejected Deferred Superseded Revoked
⸻
- CR-9AF — Decision-to-change linkage
A decision should be capable of initiating:
Decision ↓ Change ↓ Initiative ↓ Work ↓ Implementation ↓ ObservedOutcome
This connects strategy with execution.
⸻
- CR-9AG — Closed-loop transformation
This should become a signature OpenDEA capability:
Intent ↓ Objective ↓ Assessment ↓ Gap ↓ Recommendation ↓ Decision ↓ Change ↓ Implementation ↓ Observed Outcome ↓ Reassessment ↓ New Decision
This is substantially more powerful than a static EA repository.
⸻
- CR-9AH — Agent runtime interface
CR-7 defined agent semantics.
CR-9 should expose a formal interface for agents.
An agent should be able to:
discover() query() assess() reason() recommend() requestDecision() execute() report()
But each operation must be governed by:
identity authority scope policy risk approval audit
⸻
- CR-9AI — Agent capability discovery
Agents should discover capabilities through OpenDEA.
Example:
Agent: "I need a capability that can assess customer-service maturity." OpenDEA: AssessmentCapability provider: AssessmentAgent skill: DMMAssessment authorization: available
This begins to turn OpenDEA into a semantic capability registry for agents.
⸻
- CR-9AJ — Agent authorization
An agent must never be able to infer:
“I can do this because the API exists.”
Authorization should be modeled as:
Agent ↓ Role ↓ Authority ↓ Policy ↓ Scope ↓ Action
The runtime evaluates:
Can Agent X perform Action Y on Resource Z in Context C?
⸻
- CR-9AK — Policy enforcement point
Introduce a runtime policy decision point:
Agent ↓ Request ↓ Policy Decision Point ↓ ALLOW / DENY / ESCALATE ↓ Policy Enforcement Point ↓ Action
This should integrate with CR-7 governance semantics.
⸻
- CR-9AL — Human-in-the-loop
The runtime should support mandatory human approval for defined classes of action.
Example:
Risk = Low → Agent may execute Risk = Medium → Agent may execute with logging Risk = High → Human approval required Risk = Critical → Human decision mandatory
Do not hard-code these levels globally; make them policy-driven.
⸻
- CR-9AM — Agent action audit
Every agent action should produce:
action: id: agent: requestedAt: approvedBy: authority: actionType: target: policyDecision: result: evidence:
This creates an auditable agentic operating environment.
⸻
- CR-9AN — Tool registry
CR-9 should introduce a semantic Tool Registry.
Tool ├── capability ├── provider ├── interface ├── authorization ├── risk ├── dataAccess ├── availability └── version
Agents discover tools semantically.
⸻
- CR-9AO — Agent ↔ Tool ↔ Capability
This becomes a fundamental graph pattern:
Agent │ uses ↓ Tool │ provides ↓ Capability │ supports ↓ Objective
This gives OpenDEA a mechanism to reason about agentization opportunities.
⸻
- CR-9AP — Agentization analysis
The runtime should eventually answer:
Which enterprise capabilities are suitable for agentization?
Possible criteria:
high transaction volume rule-based decisions digital inputs digital outputs low physical dependency clear authority high process repeatability manageable risk
The result should be an:
AgentizationOpportunity
rather than automatically creating an agent.
⸻
- CR-9AQ — Agent orchestration
Do not embed orchestration logic into the semantic Core.
Instead:
OpenDEA ↓ Agent discovers semantic context ↓ Orchestrator plans execution ↓ Agents execute ↓ OpenDEA records actions/results
The orchestrator consumes OpenDEA; OpenDEA provides the enterprise semantic context.
⸻
- CR-9AR — Event → reasoning → action
This enables a key pattern:
Event ↓ Detect ↓ Assess ↓ Reason ↓ Decision ↓ Authorize ↓ Act ↓ Observe
Example:
Service degradation ↓ Impact analysis ↓ Critical capability affected ↓ Risk exceeds threshold ↓ Decision requested ↓ Approved ↓ Failover action ↓ Outcome recorded
⸻
- CR-9AS — Simulation boundary
CR-9 should introduce a simulation interface, but not yet build a full enterprise digital twin.
Support:
Current State + Proposed Change → Simulated State
For example:
What would happen if Application X were retired?
The engine produces an impact graph without modifying production state.
This creates the foundation for CR-10.
⸻
- CR-9AT — Digital twin distinction
OpenDEA should not claim to be a digital twin merely because it contains architecture data.
Distinguish:
Architecture Model ↓ Operational Model ↓ Observed State ↓ Simulation Model ↓ Digital Twin
CR-9 should establish the prerequisites, not prematurely collapse these concepts.
⸻
- CR-9AU — Runtime APIs
Establish a canonical API surface.
Model
GET /models GET /models/{id} POST /models
Entities
GET /entities/{id} POST /entities PATCH /entities/{id}
Graph
GET /graph/query GET /graph/path GET /graph/neighbors
Assessment
POST /assessments GET /assessments/{id}
Decisions
POST /decisions GET /decisions/{id} POST /decisions/{id}/approve
Validation
POST /validate
Reasoning
POST /reason
Agent
POST /agents/{id}/actions GET /agents/{id}/authority
These are conceptual endpoints; the implementation can evolve.
⸻
- CR-9AV — API security
All runtime APIs need:
authentication authorization tenant isolation rate limiting audit input validation policy enforcement
Agent APIs additionally require:
agent identity delegated authority action scope risk classification
⸻
- CR-9AW — Multi-tenancy
If OpenDEA is intended for enterprise SaaS or ecosystem use, establish tenant boundaries early.
Conceptually:
OpenDEA Runtime │ ┌────┼────┐ ↓ ↓ ↓ Org A Org B Org C
No graph query should accidentally cross tenant boundaries.
⸻
- CR-9AX — Environment separation
Support:
Development Test Simulation Production
Architecture models and agent actions should be environment-aware.
For example:
Agent A environment = simulation
must never automatically execute a production action.
⸻
- CR-9AY — Observability
The runtime needs its own observability model.
Track:
API latency query latency graph size ingestion rate validation failures inference rate agent actions policy denials decision latency data freshness
This is separate from enterprise observability but should be integrated with it.
⸻
- CR-9AZ — Data freshness
Every externally sourced entity should have:
lastObserved lastSynced source freshnessPolicy stalenessStatus
Example:
Application A last observed: 2026-08-18 08:30 freshness SLA: 4 hours status: Fresh
The runtime should be able to warn:
“This architecture conclusion is based on data that is 17 days old.”
That is far more useful than presenting stale data as current truth.
⸻
- CR-9BA — Data quality scoring
Introduce semantic data quality:
Completeness Accuracy Freshness Consistency Uniqueness Provenance Confidence
Then:
Architecture Confidence
can be calculated from the underlying evidence quality.
This is particularly important when architecture is assembled automatically.
⸻
- CR-9BB — Knowledge confidence
Avoid a single simplistic confidence score.
Distinguish:
Evidence confidence Identity confidence Inference confidence Data quality Source authority
For example:
Assertion confidence = 0.92 but source authority = low
should not necessarily be treated as equivalent to:
Assertion confidence = 0.90 source authority = authoritative
⸻
- CR-9BC — Provenance chain
Every material conclusion should support:
Conclusion ↓ Inference ↓ Assertions ↓ Evidence ↓ Source Systems
This enables explainable enterprise intelligence.
⸻
- CR-9BD — Architecture observability
Introduce a useful concept:
Architecture Observability
The runtime should continuously detect:
architecture drift policy drift maturity drift dependency drift technology drift agent behavior drift governance drift
For example:
Approved Architecture ↓ Observed Architecture ↓ Difference ↓ Architecture Drift
⸻
- CR-9BE — Drift engine
Create a drift service:
Reference Model + Observed State ↓ Drift Detection ↓ Deviation ↓ Risk Assessment ↓ Decision
This creates a direct bridge between architecture governance and operations.
⸻
- CR-9BF — Change detection
Changes should be classified:
Added Removed Modified Moved Reclassified RelationshipChanged StateChanged PolicyChanged
Every change should have:
who/what when source before after reason approval
⸻
- CR-9BG — Architecture baseline
Support explicit baselines:
Baseline ├── Current ├── Approved ├── Target ├── Planned └── Simulated
This is essential for transformation planning.
⸻
- CR-9BH — Target-state management
OpenDEA should support:
Current State ↓ Target State ↓ Gap ↓ Transformation ↓ Future State
The runtime should be able to compare any two states.
⸻
- CR-9BI — Graph snapshots
Support graph snapshots:
Snapshot 2026-Q1 Snapshot 2026-Q2 Snapshot 2026-Q3
This enables:
diff(snapshotA, snapshotB)
and:
trend(entity)
⸻
- CR-9BJ — Architecture scenario engine
Allow:
Scenario A Scenario B Scenario C
to coexist without affecting the production graph.
For example:
Scenario: Replace Application A with Platform B
The engine calculates:
affected capabilities cost assumptions risk dependencies maturity impact agent impact
This should become a major CR-10 capability.
⸻
- CR-9BK — Cost and value semantics
Where CR-7 introduced outcomes and decisions, CR-9 can operationalize basic economic attributes:
Cost Benefit Value Risk Investment OperatingCost OpportunityCost
But avoid creating a complete financial model inside Core.
These belong in an appropriate profile.
⸻
- CR-9BL — Decision evidence matrix
For every major decision, provide:
Dimension Evidence Strategic alignment Objective Architecture impact Impact graph Financial Cost/benefit Risk Risk model Capability Maturity Technology Dependency Governance Policy Operational Observations
This creates defensible architecture decisions.
⸻
- CR-9BM — Semantic federation
OpenDEA should support multiple semantic domains:
Enterprise Architecture │ ├── Business ├── Data ├── Application ├── Technology ├── Security ├── AI ├── Risk └── Governance
They should remain semantically connected through Core relationships.
⸻
- CR-9BN — Federation rather than centralization
Do not assume every enterprise must copy all data into OpenDEA.
Support:
OpenDEA │ ├── local graph ├── federated source ├── cached representation └── external reference
This is particularly important for:
- sensitive data;
- high-volume telemetry;
- operational systems;
- data sovereignty.
⸻
- CR-9BO — External references
An OpenDEA entity may point to:
externalUri externalId sourceSystem sourceType
without duplicating the source object.
This supports lightweight federation.
⸻
- CR-9BP — Runtime transaction semantics
Graph updates need controlled transactions.
Example:
BEGIN update Capability update Service create Change create Evidence create Assertion COMMIT
If validation fails:
ROLLBACK
The semantic graph should never be left partially updated.
⸻
- CR-9BQ — Eventual consistency
Not every integration needs synchronous consistency.
Define consistency classes:
Strong Near-real-time Eventual Periodic Manual
The model should declare which applies to each source.
⸻
- CR-9BR — Semantic cache
For high-performance queries, introduce a semantic cache.
But:
Cached knowledge must never silently become authoritative knowledge.
Every cached object retains:
source retrievedAt expiry freshness
⸻
- CR-9BS — Runtime package
A reference OpenDEA runtime could eventually look like:
opendea-runtime/ ├── api/ ├── graph/ ├── semantic/ ├── validation/ ├── inference/ ├── assessment/ ├── decision/ ├── policy/ ├── agents/ ├── integration/ ├── provenance/ ├── events/ └── observability/
⸻
- CR-9BT — Minimal viable runtime
Do not attempt to implement everything above simultaneously.
The CR-9 MVP should contain:
- Graph store abstraction
- Canonical OpenDEA model loader
- Validator
- Entity/relationship CRUD
- Basic graph queries
- Provenance
- Temporal state
- Rule engine
- Assessment execution
- REST/API interface
- Reference integration adapter
- Reference agent interface
Everything else can build incrementally.
⸻
- CR-9BU — Recommended implementation order
Phase 1 — Runtime foundation
Graph abstraction Model loader Schema validation Canonical IDs CRUD
Phase 2 — Semantic services
Rules Inference Provenance Temporal graph
Phase 3 — Enterprise integration
Mapping Connectors Events Identity resolution
Phase 4 — Intelligence
Query Assessment Impact analysis Decision support
Phase 5 — Agentic runtime
Agent discovery Tool registry Authorization Policy Actions Audit
Phase 6 — Scenario and simulation
Baselines Snapshots Scenarios What-if analysis
⸻
- CR-9BV — Reference implementation
Create a reference runtime rather than attempting a production platform.
A useful initial architecture:
REST / GraphQL
│
↓
OpenDEA Service
│
┌──────────────┼──────────────┐
↓ ↓ ↓
Validator Rule Engine Query
│ │ │
└──────────────┼──────────────┘
↓
Graph API
↓
Graph DB
The reference implementation demonstrates the semantics.
It should not become the only valid implementation.
⸻
- CR-9BW — Repository structure
Extend the CR-8 structure with runtime:
/ ├── specification/ ├── schema/ ├── profiles/ ├── models/ ├── validation/ ├── mappings/ ├── runtime/ │ ├── api/ │ ├── graph/ │ ├── inference/ │ ├── assessment/ │ ├── decision/ │ ├── policy/ │ ├── agents/ │ └── events/ │ ├── connectors/ │ ├── examples/ │ └── mappings/ │ ├── tests/ │ ├── conformance/ │ ├── runtime/ │ └── integration/ │ └── viewer/
Again, adapt this to the existing repository rather than blindly restructuring it.
⸻
- CR-9BX — Viewer evolution
The existing web viewer should evolve from:
Model Viewer
toward:
OpenDEA Explorer
with modes:
Explore Assess Trace Compare Query Simulate Govern
But the viewer remains a consumer of runtime APIs, not the runtime itself.
⸻
- CR-9BY — Explorer capabilities
The viewer should eventually allow a user to select:
Capability
and see:
Strategy Objectives Processes Services Applications Technology Data Assessment Risks Decisions Changes Agents Evidence
This makes the semantic graph tangible.
⸻
- CR-9BZ — “Why?” navigation
One particularly valuable UI capability:
Every important fact should support:
Why?
For example:
Customer Service Capability Maturity = 2.4
Click Why?
Assessment ↓ Measures ↓ Evidence ↓ Source
Or:
Strategic Capability
Click Why?
supports Objective X Objective X is Strategic
This is the UI expression of semantic provenance.
⸻
- CR-9CA — “What if?” navigation
Similarly:
What if I retire this application?
The viewer invokes:
Scenario Engine ↓ Impact Graph
and presents:
Capabilities affected: 7 Services affected: 12 Objectives affected: 2 Agents affected: 4 Risk increase: ...
This should become one of the defining OpenDEA experiences.
⸻
- CR-9CB — “What can act?” navigation
For agentic architecture:
Select:
Business Capability
and ask:
Which agents can currently act on this capability?
The graph traverses:
Capability ↓ Service ↓ Action ↓ Agent ↓ Authority ↓ Policy
This gives an enterprise a live map of its agentic operating model.
⸻
- CR-9CC — Semantic API for AI agents
Expose an agent-oriented API:
discover(context) query(intent) retrieve(entity) explain(assertion) assess(scope) recommend(decisionContext) requestAuthority(action) recordAction(result)
This should become the preferred mechanism for enterprise agents to consume architecture knowledge.
⸻
- CR-9CD — Agent context construction
The runtime should construct an agent’s context from OpenDEA.
Instead of sending an agent an enormous enterprise document:
Enterprise Model ↓ Agent Context Query ↓ Relevant subgraph ↓ Policy filtered ↓ Authority filtered ↓ Context supplied to Agent
This is a major architectural advantage.
⸻
- CR-9CE — Context minimization
The runtime should provide only the semantic context necessary for the requested task.
For example:
Agent task: Assess capability maturity.
The context might contain:
Capability Assessment Evidence Target Relevant services Relevant policies
rather than the entire enterprise graph.
This improves:
- performance;
- security;
- explainability;
- LLM accuracy.
⸻
- CR-9CF — Semantic access control
Access control should operate at graph level.
Potentially:
User/Agent ↓ Policy ↓ Entity ↓ Relationship ↓ Property
This allows:
Agent can see Capability but cannot see financial property. Agent can see Application but cannot see security vulnerability. Agent can recommend Decision but cannot approve Decision.
This is much more powerful than endpoint-only security.
⸻
- CR-9CG — Security classification
Support semantic data classification:
Public Internal Confidential Restricted HighlyRestricted
Then policies can enforce access.
This should be implemented through a Security/Governance profile rather than polluting Core.
⸻
- CR-9CH — Runtime lifecycle
The runtime itself should have lifecycle states:
Model → Imported → Validated → Active → Superseded → Archived
Entities may independently have their own lifecycle.
Do not conflate model lifecycle with entity lifecycle.
⸻
- CR-9CI — Runtime audit log
Every material runtime mutation should create an audit event:
Who What When Why Before After Source Authorization
For AI agents additionally:
Model/version Prompt/context reference Policy decision Tool invoked Outcome
Do not necessarily store raw prompts in the semantic graph; store appropriate references where privacy and security requirements dictate.
⸻
- CR-9CJ — Performance objectives
Define baseline runtime targets.
For the reference implementation:
Model validation: < 2 seconds for 10k entities Simple entity query: < 200 ms Typical graph traversal: < 500 ms Standard impact analysis: < 2 seconds
These are initial engineering targets, not semantic requirements.
Benchmark against actual representative datasets before treating them as contractual SLAs.
⸻
- CR-9CK — Scale testing
Create synthetic enterprise models:
1K entities 10K entities 100K entities 1M entities
Test:
load query traversal validation inference snapshot diff
This will expose whether the conceptual model is computationally practical.
⸻
- CR-9CL — Runtime conformance
CR-8 established semantic conformance.
CR-9 adds:
Runtime conformance.
An implementation should be able to demonstrate:
Core Conformance Profile Conformance API Conformance Query Conformance Validation Conformance Provenance Conformance Security Conformance
This allows multiple independent runtime implementations.
⸻
- CR-9CM — Interoperability test suite
Create:
OpenDEA Interoperability Test Suite
For each adapter:
Source ↓ Mapping ↓ OpenDEA ↓ Validation ↓ Graph ↓ Query
The same expected semantic result should be obtained regardless of source.
⸻
- CR-9CN — Golden graph
CR-8 used golden models.
CR-9 adds golden graphs.
Example:
golden-enterprise.graph
Expected properties:
Nodes = X Edges = Y Assertions = Z
and specific traversal results:
Capability → Service = expected set Agent → Authority = expected set Objective → Capability = expected set
This becomes a regression artifact.
⸻
- CR-9CO — Runtime test categories
Create:
Unit Semantic Graph Inference Integration Security Performance Agentic End-to-End
The test suite should run automatically in CI/CD.
⸻
- CR-9CP — CI/CD quality gate
A proposed merge should fail if:
schema validation fails golden models fail semantic tests fail runtime tests fail mapping tests fail security tests fail
This is important because CR-9 introduces much more moving semantic machinery.
⸻
- CR-9CQ — No silent inference
A critical rule:
The runtime must never silently convert inferred knowledge into authoritative fact.
Instead:
Observed Inferred Proposed Approved
remain distinct.
An AI can propose:
Capability X appears strategic.
But it cannot silently rewrite:
Capability X = strategic
without an explicit state transition.
⸻
- CR-9CR — No autonomous mutation by default
Similarly:
Agents are read-only by default.
An agent gets mutation rights only through explicit:
authority policy scope approval
This should be a foundational runtime security principle.
⸻
- CR-9CS — The OpenDEA semantic loop
Once CR-9 is implemented, the core loop becomes:
┌──────────────┐
│ Observe │
└──────┬───────┘
↓
┌──────────────┐
│ Model │
└──────┬───────┘
↓
┌──────────────┐
│ Assess │
└──────┬───────┘
↓
┌──────────────┐
│ Reason │
└──────┬───────┘
↓
┌──────────────┐
│ Decide │
└──────┬───────┘
↓
┌──────────────┐
│ Act │
└──────┬───────┘
↓
┌──────────────┐
│ Observe │
└──────────────┘
This is the conceptual centerpiece of CR-9.
⸻
- CR-9CT — Recommended repository milestones
Break the implementation into the following changes:
CR-9.1
Runtime Foundation
Graph abstraction, model loading, entity/relationship APIs.
CR-9.2
Knowledge Graph
Canonical graph representation and provenance.
CR-9.3
Semantic Reasoning
Rules, inference and explainability.
CR-9.4
Temporal & Event Runtime
Events, state, snapshots, temporal queries.
CR-9.5
Integration Framework
Adapters, mapping, identity resolution.
CR-9.6
Assessment Runtime
DMM and other assessment execution.
CR-9.7
Decision & Impact Engine
Decision support, impact analysis, change linkage.
CR-9.8
Agent Runtime
Agent discovery, authority, policy, actions and audit.
CR-9.9
OpenDEA Explorer
Viewer decoupled from the runtime and driven by APIs.
CR-9.10
Conformance & Interoperability Release
Golden graph, interoperability suite, performance suite and reference runtime release.
⸻
- CR-9 Definition of Done
CR-9 should not be considered complete merely because a graph database has been added.
The actual acceptance criteria are:
[ ] OpenDEA models can be loaded into a runtime [ ] Canonical entities and relationships are preserved [ ] Graph queries work independently of graph vendor [ ] Provenance is retained [ ] Temporal state is supported [ ] External sources can be mapped into OpenDEA [ ] Entity identity can be resolved safely [ ] Rules can generate derived assertions [ ] Every inference is explainable [ ] DMM assessments can execute against the model [ ] Impact analysis can traverse dependencies [ ] Decisions can reference evidence and architecture [ ] Agent authority can be evaluated [ ] Agent actions are auditable [ ] Runtime APIs are defined [ ] Viewer consumes runtime APIs rather than defining semantics [ ] Golden graphs pass [ ] Interoperability tests pass [ ] Runtime security is enforced [ ] Stale data is detectable [ ] No inferred fact silently becomes authoritative
⸻
- The architectural significance of CR-9
CR-8 gave OpenDEA this:
SEMANTIC SPECIFICATION
│
↓
"What does this mean?"
CR-9 adds:
SEMANTIC RUNTIME
│
↓
"What can we do with it?"
Together:
OPENDEA
│
┌─────────┴─────────┐
↓ ↓
CR-8 CR-9
Meaning Execution
│ │
↓ ↓
Specification Runtime
│ │
└─────────┬─────────┘
↓
Semantic Enterprise
│
┌───────────┼───────────┐
↓ ↓ ↓
Model Assess Reason
↓ ↓ ↓
Observe Decide Act
└───────────┼───────────┘
↓
Outcome
↓
Learn
That is the point at which OpenDEA stops being primarily a metamodel and starts becoming an architecture intelligence platform.
The most important discipline for CR-9 is therefore not to overbuild the runtime. The semantic contract established in CR-8 must remain authoritative, while the runtime provides interchangeable implementations of graph, inference, integration, assessment and agentic services. This separation is what will allow OpenDEA to evolve into a genuine ecosystem rather than becoming tightly coupled to the current web viewer or a particular technology stack.