Architectural Data vs Architectural Knowledge¶

Why this distinction matters¶

Every enterprise architecture team produces information — application inventories, technology standards lists, capability maps, deployment diagrams, architecture decisions, integration catalogs, risk registers. Most of this lives in spreadsheets, wikis, modeling tools, and slide decks.

The industry routinely calls all of it "architectural knowledge." But most of it isn't knowledge — it's data or, at best, structured information. There's a fundamental difference between recording that Application X exists and understanding why it exists, what it serves, what would break if it changed, and what should replace it. The first is architectural data (or information). The second is architectural knowledge. The label doesn't change the substance.

This distinction isn't academic — it's the difference between an architecture repository that produces reports and one that supports decisions:

It determines whether your architecture practice can answer questions or only produce inventories
It determines whether AI agents can reason about your enterprise or only retrieve facts from a catalog
It determines whether architecture governance is automated and continuous or manual and periodic
It determines whether your architecture knowledge management scales beyond the architects who created it

If you've ever experienced the "ask the architect" bottleneck — where answering a cross-cutting question requires finding the one person who holds the context in their head — you've experienced this gap firsthand. The knowledge exists, but it's not formalized, not queryable, and not accessible to anyone (or any AI) except the person who built it.

This article examines what separates data from knowledge in enterprise architecture, why most EA repositories stay at the data level, and what it takes to cross the gap — practically, not theoretically.

Semantic assets — taxonomies, ontologies, and validation shapes — transform architectural data into actionable knowledge.

Definitions¶

Architectural data — the "what exists" layer¶

Architectural data is the collection of recorded facts about an enterprise's architecture. It answers what exists and what properties it has. If you can export it from a tool or harvest it from a running system, it's probably data.

Examples:

An application inventory listing 400 applications with their names, owners, lifecycle states, and technology stacks
A CMDB containing configuration items, their relationships, and operational metadata
A Backstage catalog with services, APIs, teams, and dependencies
An ArchiMate model file containing elements and relationships
A list of technology standards with approval status and sunset dates
A cost allocation spreadsheet mapping applications to cost centers

Architectural data is factual, observable, and (in principle) verifiable against running systems. It can be wrong — the CMDB is always stale — but its intent is to record what is.

Characteristics:

Descriptive — states what exists
Flat or weakly structured — rows in a table, nodes in a graph, elements in a model
Tool-extractable — much of it can be harvested from running systems (discovery tools, APM, cloud APIs)
Perishable — decays as the estate changes
Context-free — a fact without interpretation ("Application X uses Java 11" says nothing about whether that's a problem)

Architectural knowledge — the "why and what to do" layer¶

Architectural knowledge is the interpreted, contextualized understanding that gives architectural data meaning. It answers why things exist, what they mean in context, what should change, and what the consequences of change would be. This is what experienced architects carry in their heads — and what leaves the organization when they do.

Examples:

The rationale for choosing microservices over a monolith for the payment platform
The understanding that Business Capability "Customer Onboarding" is served by three applications, two of which are redundant, and the third is the strategic target
The recognition that decommissioning Platform Y would break Capability Z because of an undocumented integration through Service Q
The governance principle that all customer-facing services must have sub-200ms P99 latency, and the reasoning behind that threshold
The pattern language that guides architects toward event-driven integration for cross-domain workflows
The assessment that Application X's technical debt makes it unsuitable for the AI-augmented target state

Architectural knowledge is interpretive, contextual, and often tacit. It lives in architects' heads, in decision records (when they exist), in the implicit structure of capability maps, and in the unwritten rules that govern technology selection.

Characteristics:

Interpretive — assigns meaning to facts
Relational — derives value from connections between concepts across layers and domains
Contextual — the same fact means different things in different organizational contexts
Durable — principles, patterns, and rationale outlive individual systems
Actionable — directly supports decisions ("given this knowledge, we should do X")

The DIKW progression — and the role of semantic engines¶

The distinction between data and knowledge isn't a binary — it's a progression. What most organizations have sits at the Data or Information level. True knowledge requires applying formal semantic structure.

The Data–Information–Knowledge–Wisdom (DIKW) hierarchy provides the frame for understanding what each layer adds. But the crucial insight is: the transitions between layers aren't magic — they're performed by specific semantic engines. Taxonomies, ontologies, and validation shapes are the formal scaffolding that elevates raw data into machine-traversable knowledge.

Each DIKW transition is performed by a specific semantic engine. Most EA repositories stop at the Information level.

Level	Architecture example	What it adds	Semantic asset that performs the transition
Data	`"App-042"`, `"Java 11"`, `"eu-west-1"`	Raw symbols — no context, no meaning	—
Information	"App-042 is an `am:ApplicationComponent` owned by Team Payments, classified as `timefw:Invest`, serving 3 `am:BusinessCapability` instances"	Structure, classification, typed relationships	SKOS taxonomies provide shared vocabulary; OWL class declarations give elements a type
Knowledge	"App-042 is the strategic payment platform because it's the only one that `am:realizes` the PCI-DSS-compliant payment service. Removing it eliminates the capability (inferred: no alternative realization path exists)."	Inference, reasoning, actionability	OWL classifies (open-world); SPARQL + SHACL draw the consequential, negation-dependent conclusions (closed-world)
Wisdom	"Payment platforms should be consolidated early in any acquisition because payment is a capability where duplication creates regulatory risk"	Generalized principles derived from experience	Architecture decisions extension (`ad:`) encodes rationale; SHACL governance shapes encode principles as executable rules

The crucial leap is Information → Knowledge. It requires that meaning be made explicit and machine-processable, not just human-readable. This is where ontologies earn their keep — but it pays to be precise about which engine does what. All three semantic engines (OWL, SPARQL, SHACL) read the same typed graph, but they operate under different logical assumptions and answer different kinds of question. OWL classifies under the open-world assumption; SPARQL and SHACL draw consequential, negation-dependent conclusions under a closed-world assumption. Together they turn "data with some structure" into "knowledge a machine can traverse and reason over."

Most EA tools operate at the Data and Information levels. They store elements, relationships, and properties. The Knowledge and Wisdom levels typically remain in people's heads or in unstructured documents — unless you formalize them with the right semantic assets.

A note on DIKW. DIKW is a useful narrative scaffold, not a law — its upper rungs, especially "wisdom," are contested in information science (see Frické 2009; Rowley 2007). Linked.Archi's claim doesn't depend on the hierarchy being literally clean: the mechanism is that formal semantic structure is what turns human-readable information into machine-traversable knowledge, and that holds regardless of how many rungs you draw.

What each engine actually does¶

All three semantic engines read the same typed graph, but they answer fundamentally different kinds of question — and they operate under different logical assumptions. Keeping them straight is the difference between a correct mental model and a misleading one.

One typed RDF graph, three engines with different assumptions — OWL classifies (open-world), SPARQL traverses (closed-world), SHACL validates (closed-world).

Engine	Assumption	Question it answers	Example
OWL reasoner	Open-world	What kind of thing is this?	App is an `arch:Element`; TIME assigns the Migrate quadrant
SPARQL query	Closed-world	What does it connect to?	Which capabilities does this app ultimately support?
SHACL validator	Closed-world	Is it well-formed and compliant?	Every component has an owner; a SPOF needs a mitigation plan

This is exactly the division Linked.Archi already adopts as a design principle — OWL for meaning, SHACL for validation — the explanation below makes the reasoning roles explicit so the inference claims don't overreach.

How Linked.Archi's semantic assets drive each transition¶

This is the core mechanism. Each type of semantic asset in meta.linked.archi performs a specific role in the DIKW progression:

How Linked.Archi's semantic assets drive each DIKW transition — from raw exports to encoded wisdom. The Info→Knowledge step is performed by both OWL (classification, open-world) and SPARQL+SHACL (consequence, closed-world).

Data → Information: SKOS taxonomies and OWL type declarations¶

The problem at this level: Raw architecture data uses inconsistent terminology. One team calls it a "service," another calls it an "application," a third calls it a "component." The same concept has five names across five tools. There's no shared vocabulary, no classification hierarchy, no way to know that two things refer to the same concept.

What Linked.Archi provides:

SKOS taxonomies (*-tax.ttl files) give every modeling language a controlled vocabulary with skos:broader/ skos:narrower hierarchies. The ArchiMate taxonomy classifies 62 element types into layers and aspects. The TOGAF taxonomy organizes ADM phases, viewpoints, and deliverable types. These ensure that the same concept is always called the same thing.
OWL class declarations (*-onto.ttl files) give every element a formal type. When an ArchiMate XML export says <element xsi:type="ApplicationComponent">, the converter maps it to am:ApplicationComponent — a class with defined semantics, a position in the class hierarchy, and known relationships to other types.

Concrete example:

Raw data:    "CRM" (a cell in a spreadsheet)
                    ↓ apply SKOS taxonomy + OWL typing
Information: ex:crm-system a am:ApplicationComponent ;
                 skos:prefLabel "CRM System"@en ;
                 am:layer am:ApplicationLayer ;
                 bs:ownedBy ex:team-sales .

The string "CRM" became a typed, classified, labeled entity in a shared vocabulary. It's now information — structured, unambiguous, and machine-readable. But it's not yet knowledge — you can't infer anything from it beyond what's explicitly stated.

Information → Knowledge: classification and consequence¶

The problem at this level: You have structured information — typed elements with properties and named relationships. But the relationships are just labels. "App-042 realizes Payment Service" is stated; the open question is which engine lets you act on it, and what each one can legitimately conclude.

What Linked.Archi provides:

OWL gives relationships and types formal meaning — classification under the open-world assumption. am:realizes is an owl:ObjectProperty with documented intent, not a free-text label. And am:ApplicationComponent rdfs:subClassOf arch:Element lets a reasoner classify instances by type. OWL's strength here is subsumption and classification — it answers "what kind of thing is this, and what does that entail?" The TIME framework's owl:equivalentClass definitions are the clearest payoff: an application with the right fit scores is automatically classified into the Migrate quadrant by the reasoner, with no hand-written rule.
SPARQL traverses the chains that produce consequence — closed-world. Whether "App-042 realizes Service-X, which realizes Capability-Y, therefore App-042 provides Capability-Y" is entailed depends on a deliberate choice: it requires an OWL 2 owl:propertyChainAxiom (realizes ∘ realizes ⊑ provides), which goes beyond Linked.Archi's minimal OWL profile. In the default profile this traversal is a SPARQL property path (am:realizes+) — a query, not an entailment. Both are valid; what matters is knowing which engine you're relying on.
SHACL makes "what breaks if…" answerable — and it is closed-world by design. The conclusion "App-042 is a single point of failure" rests on no other component realizes the service. That is negation as failure, and OWL cannot draw it: under the open-world assumption, the absence of a stated alternative means "unknown," not "none." This reasoning belongs to SPARQL (FILTER NOT EXISTS) and SHACL, which operate under a closed-world, validation mindset.
Cross-language connectivity via arch:core means an ArchiMate application component and a Backstage component representing the same system can be linked — by default with skos:exactMatch (correspondence: interchangeable for querying, no reasoner required, native types preserved), or with owl:sameAs in the documented cases where the two are confirmed to be one individual and a full property merge is wanted. Either way, a SPARQL query can then traverse from Backstage ownership through ArchiMate capability mappings — impossible when the data lived in separate tools. See DD-11 for the full rationale.

The realization chain worked example — OWL classifies nodes (open-world), SPARQL follows property paths (closed-world), and SHACL/SPARQL detects single points of failure via negation as failure. OWL cannot draw the SPOF conclusion.

Concrete example — which engine does what:

Information: ex:crm-system a am:ApplicationComponent .
             ex:crm-system am:realizes ex:customer-mgmt-service .
             ex:customer-mgmt-service am:realizes ex:customer-onboarding-cap .

  ── OWL reasoner (OPEN-world): classification & subsumption ──
  ✓ ex:crm-system a arch:Element            (via rdfs:subClassOf)
  ✓ ex:crm-system a timefw:Migrate          (via owl:equivalentClass, if fit scores present)

  ── SPARQL (CLOSED-world): chain traversal & consequence ──
  ?cap  WHERE { ex:crm-system am:realizes+ ?cap }   → ex:customer-onboarding-cap
  SPOF ⇐ FILTER NOT EXISTS { ?other am:realizes ex:customer-mgmt-service }

  ── SHACL (CLOSED-world): make the graph trustworthy enough to reason over ──
  ✓ realization chain complete & well-formed; every component has an owner

This is the moment data becomes knowledge — but it pays to be precise about which engine does the work. OWL classifies (open-world); SPARQL and SHACL draw the consequential, negation-dependent conclusions (closed-world). The ontology supplies the shared, typed meaning that makes the query expressible; the query engine supplies the answer. Conflating the two hides the fact that "what breaks if we remove this?" is fundamentally a closed-world question.

Knowledge → Wisdom: Architecture decisions and governance principles¶

The problem at this level: You have a knowledge graph that supports inference and cross-domain queries. But it doesn't encode why things are the way they are, or what principles should guide future decisions. An AI agent can tell you what exists and what depends on what — but it can't tell you what the organization should do without access to decision rationale and governance principles.

What Linked.Archi provides:

Architecture decisions extension (ad:) makes rationale first-class graph entities. A decision links to the forces that drove it, the options that were considered, the tradeoffs that were accepted, and the elements it affects. This is the "decision trace" — the why behind the what.
Governance SHACL shapes encode organizational principles as executable constraints. "Cross-domain integrations must use event-driven patterns" isn't a PDF that nobody reads — it's a SHACL shape that fires a warning when someone models a synchronous cross-domain collaboration. Principles become active knowledge that participates in validation.
Reference architecture patterns (ref-arch:) encode reusable architectural tactics — proven solutions to recurring quality attribute challenges. When an architect faces a scalability problem, the graph contains patterns that address it, linked to the quality attributes they optimize and the tradeoffs they introduce.
TIME framework with OWL equivalent classes automatically classifies applications into Tolerate/Invest/Migrate/Eliminate quadrants based on their functional and technical fit scores. This is wisdom encoded as inference rules — the classification happens automatically when the evidence is present.

Concrete example:

Knowledge:   ex:crm-system is a single provider for ex:customer-onboarding-cap
             ex:crm-system has technical debt score 7/10
                    ↓ apply ad: decisions + governance SHACL + TIME inference
Wisdom:      ex:decision-089 a ad:Decision ;
                 ad:rationale "CRM must be replaced because single-provider risk
                              for a critical capability combined with high tech debt
                              makes it unsuitable for the AI-enabled target state" ;
                 ad:addresses ex:force-resilience, ex:force-modernization ;
                 ad:outcome "Migrate to cloud-native CRM within 18 months" .

             # TIME framework infers: ex:crm-system timefw:classification timefw:Migrate
             # (based on: high technical debt + strategic capability = Migrate quadrant)

             # Governance SHACL encodes the principle:
             # "Single-provider capabilities must have a documented mitigation plan"

The knowledge graph now contains not just what exists and what it means, but why decisions were made and what principles guide future ones. An AI agent with access to this graph can recommend actions, not just report facts.

The semantic asset toolkit — summary¶

A useful mental model: the ontology is the schema/grammar (what's meaningful and inferable), the taxonomy is the vocabulary (the words and their hierarchy), and SHACL is the spell-checker and style guide (what's well-formed and required). Data flows through all three to become knowledge.

Semantic Asset	Role in DIKW	What it does in Linked.Archi	Example file
SKOS Taxonomy	Data → Information	Shared vocabulary, classification hierarchies, controlled terms	`archimate-tax.ttl`, `togaf-tax.ttl`
OWL Ontology	Information → Knowledge	Classification, subsumption, type inference (open-world)	`archimate-onto.ttl`, `core-onto.ttl`
SPARQL Queries	Information → Knowledge	Chain traversal, consequence, negation (closed-world)	property paths, `FILTER NOT EXISTS`
SHACL Shapes	Information → Knowledge + Guards quality	Validates completeness; encodes governance rules; enables negation-based reasoning	`archimate-shapes.ttl`, `core-shapes.ttl`
Architecture Decisions (`ad:`)	Knowledge → Wisdom	Captures rationale, forces, options, tradeoffs — the "why"	`archDecision.ttl`
Reference Architecture (`ref-arch:`)	Knowledge → Wisdom	Reusable patterns and tactics linked to quality attributes	`ref-arch-onto.ttl`
TIME Framework	Knowledge → Wisdom	Automatic portfolio classification via OWL equivalent classes	`time-onto.ttl`
Deliverable Templates	Wisdom → Action	SPARQL-driven document generation — wisdom becomes stakeholder communication	`*-deliverable-templates.ttl`

Linked.Archi's semantic assets organized by their role in the DIKW progression.

Where the gap shows up in practice¶

The "ask the architect" problem¶

When someone asks "can we decommission Platform Y?" — the data says Platform Y exists and has certain properties. The knowledge required to answer the question includes:

The knowledge required to answer a decommissioning question far exceeds the data available in repositories.

An architect who has worked with Platform Y for five years can answer this in a meeting. But that answer isn't recorded, isn't queryable, isn't available at 2am when an incident responder needs it, and leaves the organization when the architect does.

The AI grounding problem¶

AI agents can retrieve data. They can look up "what applications exist in domain X" if you give them access to an inventory. What they can't do without architectural knowledge is reason about consequences, evaluate compliance, or recommend actions:

An AI agent with only data is a search engine. An AI agent with a knowledge graph is an architecture advisor.

This is why Forrester's context graph analysis identifies two layers that must converge: the entity graph (data) and the decision trace (knowledge). An AI agent with only the entity graph is a search engine. An AI agent with both is an architecture advisor.

The governance automation problem¶

Governance based on architectural data alone can check: "does every application have an owner?" (property completeness) or "is this relationship type valid in ArchiMate?" (metamodel conformance).

Governance based on architectural knowledge can check: "does this proposed design align with our integration principles?" or "is this technology selection consistent with our target state?" or "does this migration plan account for the dependencies identified in the last portfolio review?"

The first is SHACL validation against structural rules — which Linked.Archi already supports via validate.sh in CI/CD. The second requires encoded principles, patterns, and decision rationale — knowledge, not just data.

What transforms data into knowledge — the ontology as engine¶

The gap between architectural data and architectural knowledge isn't bridged by collecting more data. More rows in the CMDB don't create understanding. The gap is bridged by applying ontologies — formal semantic models that make meaning explicit and machine-processable.

This is the core insight: the ontology is what makes the query expressible; the query engine is what supplies the answer. The meaning lives in the model, not in a human's head. When you define that am:realizes is a typed relationship with formal semantics, you've given SPARQL the vocabulary to traverse realization chains. When you define that am:ApplicationComponent rdfs:subClassOf arch:Element, you've given OWL the hierarchy to classify instances. When you add a SHACL shape that requires every component to have an owner, you've encoded a governance principle as executable knowledge. All three engines converge on the same typed graph — each contributing what the others cannot.

The five specific transformations that ontologies enable in enterprise architecture:

The five specific transformations that ontologies enable — from generic links and raw facts to semantic predicates and consequence models.

1. Typed relationships with semantics¶

Data: "App-042 is connected to Capability-017"

Knowledge: "App-042 realizes Business Service 'Payment Processing' which realizes Business Capability 'Customer Payments' — meaning App-042 is a direct provider of this capability, and removing it would eliminate the capability unless an alternative realization path exists."

The difference is typed, semantically meaningful relationships that support inference. In RDF/OWL terms: am:realizes has formal semantics that a reasoner can traverse, while "is connected to" does not.

2. Decision rationale¶

Data: "The payment platform uses event-driven architecture"

Knowledge: "The payment platform uses event-driven architecture because the 2025 architecture review identified that synchronous integration between payment and fulfillment created cascading failures during peak load. The decision was evaluated against three alternatives (synchronous REST, shared database, message queue) and event-driven was selected for resilience and independent scalability. The tradeoff accepted was eventual consistency in order status reporting."

The decision record transforms a fact into actionable knowledge. Future architects know not just what was chosen but why, what was rejected, and what constraints apply.

3. Classification and assessment¶

Data: "App-042 exists"

Knowledge: "App-042 is classified as Invest in the TIME framework because it's the strategic target for payment processing, has the lowest technical debt score in its domain, and is the only platform with the architectural characteristics required for the AI-enabled target state."

Classification without rationale is data. Classification with rationale, evidence, and connection to strategy is knowledge.

4. Patterns and principles¶

Data: "Services A, B, and C all use event-driven integration"

Knowledge: "Cross-domain integration should use event-driven patterns because our architecture principles require loose coupling between bounded contexts. This principle exists because the 2024 incident analysis showed that 73% of cascading failures originated from synchronous cross-domain calls. Exceptions require an architecture decision record with explicit risk acceptance."

Patterns and principles encode generalized architectural knowledge — the "wisdom" layer that guides future decisions.

5. Impact and dependency semantics¶

Data: "App-042 depends on Service-X"

Knowledge: "App-042 has a critical runtime dependency on Service-X for payment authorization. If Service-X is unavailable for more than 30 seconds, App-042 enters degraded mode and queues transactions. If unavailable for more than 5 minutes, payment processing stops entirely. This dependency cannot be removed without re-architecting the authorization flow, estimated at 6 months effort."

The dependency fact becomes knowledge when annotated with criticality, failure behaviour, and remediation context.

The spectrum, not the binary¶

In practice, architectural data and architectural knowledge exist on a spectrum — not a binary switch. A well-structured model with typed relationships and classification is more knowledge-like than a flat spreadsheet, even if it lacks explicit decision rationale. Most organizations sit somewhere in the middle and can move incrementally toward the knowledge end:

The spectrum from raw spreadsheets to a full knowledge graph — each step adds semantic richness and is independently valuable.

Each step adds semantic richness — and each step is independently valuable:

Spreadsheet → CMDB/Catalog: Adds structure, relationships, and lifecycle management. You can now ask "what exists?" without manual inventory.
CMDB → Typed model (ArchiMate, UML, C4): Adds formal element types, relationship semantics, and metamodel constraints. You can now validate structural correctness.
Typed model → Annotated model: Adds decisions, assessments, quality attributes, and governance context. You can now ask "why?" and "what should change?"
Annotated model → Knowledge graph: Adds inference, cross-domain connectivity, queryability, and machine-readability. AI agents can now reason about your architecture.

Most organizations are somewhere in the middle. They have structured data (catalogs, models) but haven't formalized the knowledge layer (decisions, rationale, principles, impact semantics). The move from typed model to knowledge graph is where architecture knowledge management becomes possible at scale.

Why most EA repositories contain data, not knowledge¶

Several structural factors keep EA repositories at the data level:

Tool design¶

Most EA tools are optimized for drawing and storing models — elements, relationships, views. They provide excellent support for the "what exists" question. They provide weak support for "why it exists" (decision rationale), "what it means" (assessment and classification with evidence), and "what should change" (target state with migration rationale).

The tool shapes the practice. If the tool makes it easy to draw boxes and arrows but hard to record decisions, you get models without rationale.

Incentive structures¶

Architecture data is easy to audit: "do we have a model for every domain?" Architecture knowledge is hard to audit: "do our models contain sufficient rationale to support autonomous decision-making?" Organizations measure what's easy to measure, which incentivizes data collection over knowledge formalization.

The tacit knowledge problem¶

Much architectural knowledge is tacit — it exists in experienced architects' heads as pattern recognition, heuristics, and contextual judgment. Making this explicit requires deliberate effort: writing decision records, documenting principles with rationale, recording assessment criteria. This effort competes with delivery pressure.

Format limitations¶

Even when architects do record knowledge (in Confluence pages, ADR files, meeting notes), it's typically in unstructured natural language disconnected from the model. The decision exists, but it's not linked to the elements it affects. The principle exists, but it's not encoded as a constraint that can be validated. The assessment exists, but it's not queryable.

What an architecture knowledge graph adds¶

A knowledge graph is what you get when you instantiate data against an ontology: data + ontology = knowledge graph. Specifically, an ontology-based architecture knowledge graph using semantic web standards addresses the structural barriers that keep EA repositories at the data level:

Formal semantics for relationships¶

Instead of generic "connects to" links, relationships have types with defined semantics: am:realizes, ad:addresses, arch:governedBy, fina:hasCostModel. These typed relationships are what make consequential queries expressible. A SPARQL property path (am:realizes+) traverses the chain from a component to the capabilities it ultimately supports, and a closed-world FILTER NOT EXISTS identifies where it is the only support — the single-point-of-failure case. OWL contributes the classification layer (an am:ApplicationComponent is an arch:Element; a qualifying application is a timefw:Migrate case); the chain-following and the "is there an alternative?" negation are SPARQL/SHACL operating under a closed-world assumption. A generic "is connected to" link in a drawing tool carries no type a query can pivot on — which is why it supports none of this.

In technical terms: an ArchiMate ontology expressed in RDF/OWL gives relationships formal semantics that make queries expressible, while a generic "is connected to" link in a drawing tool does not. The difference is whether a machine can follow the chain of consequences — and that requires both the typed vocabulary (OWL) and the traversal engine (SPARQL).

First-class decision records¶

Architecture decisions aren't separate documents — they're graph entities linked to the elements they affect:

ex:decision-042
    a                   ad:Decision ;
    ad:status           ad:Accepted ;
    ad:rationale        "Event-driven integration selected for cross-domain workflows..." ;
    ad:addresses        ex:force-resilience, ex:force-scalability ;
    ad:relatedConcept   ex:payment-platform, ex:fulfillment-service ;
    ad:consideredOption ex:option-sync-rest, ex:option-shared-db, ex:option-event-driven .

The decision is queryable, linked, and traversable. An AI agent — can answer "why does the payment platform use event-driven architecture?" by traversing the graph.

Encoded governance¶

Principles and constraints become SHACL shapes — executable knowledge:

ex:CrossDomainIntegrationShape
    a              sh:NodeShape ;
    sh:targetClass am:ApplicationCollaboration ;
    sh:property    [ sh:path     am:usesPattern ;
                     sh:hasValue ex:event-driven-pattern ;
                     sh:message  "Cross-domain integrations must use event-driven patterns (Principle P-007)" ;
                     sh:severity sh:Warning ] .

This transforms a principle from a PDF that nobody reads into a validation rule that runs in CI/CD.

Cross-layer queryability¶

The knowledge graph connects layers that tools keep separate:

# "What capabilities are at risk if we decommission Platform Y?"
PREFIX am: <https://meta.linked.archi/archimate3/onto#>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>

SELECT ?capability ?risk_level WHERE {
    ex:platform-y am:realizes ?service .
    ?service am:realizes ?capability .
    FILTER NOT EXISTS {
        ?alternative am:realizes ?service .
        FILTER (?alternative != ex:platform-y)
    }
    BIND ("CRITICAL - single provider" AS ?risk_level)
}

This query encodes knowledge: a capability served by a single provider is at critical risk if that provider is removed. The query itself is a formalization of architectural reasoning.

Practical implications for architecture teams and tooling¶

For architecture teams¶

Audit your repository honestly. Is it a data store (inventory of what exists) or a knowledge base (interpretive layer that supports decisions)? Most are data stores with aspirations.
Start with decisions. The highest-leverage knowledge formalization is recording architecture decisions with rationale, alternatives considered, and links to affected elements. This is the "decision trace" that Forrester identifies as the missing layer.
Encode principles as constraints. Every architecture principle that can be expressed as a structural rule should become a SHACL shape. This transforms knowledge from documents into executable governance.
Add "why" to classifications. TIME assessments, technology radar positions, and lifecycle states are data without rationale. Add the evidence and reasoning that supports each classification.
Connect, don't duplicate. The knowledge isn't in any single model — it's in the connections between models, decisions, assessments, and principles. A knowledge graph makes these connections explicit.

For tool selection and architecture modeling tools¶

Tools that store models but not decisions are data tools (most EA modeling tools today)
Tools that store decisions but don't link them to model elements are document tools (Confluence, ADR repos)
Tools that link decisions to elements but can't validate principles are modeling tools (Archi, Sparx EA with extensions)
Tools that do all of the above and support inference are knowledge tools (ontology-based platforms, architecture knowledge graphs)

Most organizations need a combination. The question is whether the combination is integrated (shared semantic architecture model) or siloed (separate tools with manual cross-referencing).

For AI enablement¶

AI agents need knowledge, not just data. Giving an AI agent access to an application inventory lets it answer "what applications exist in domain X?" Giving it access to a knowledge graph lets it answer "what should we do about the payment platform?" — because it can traverse from the platform through its capabilities, decisions, assessments, dependencies, and principles to construct a reasoned recommendation.

The Linked.Archi toolbox includes an MCP server that loads the RDF graph into an in-memory SPARQL engine (Oxigraph) and exposes it to AI agents. An architect can ask a natural language question; the agent translates to SPARQL, queries the graph, and returns a grounded answer — not hallucinated from training data, but derived from the actual architecture model.

The difference between a chatbot that retrieves facts and an AI architecture advisor that reasons about your enterprise is the difference between architectural data and architectural knowledge.

The Linked.Archi position¶

Linked.Archi is designed as a knowledge graph, not a data store. The architecture reflects this:

Linked.Archi's three-layer architecture — from imported data through semantic connectivity to inference and governance.

arch:core (v0.3.2) provides the semantic foundation — typed elements, qualified relationships, viewpoints, concerns. Aligned with ISO/IEC/IEEE 42010. This is the structural layer that elevates data toward knowledge.
Architecture decisions extension (ad:) provides first-class decision records linked to affected elements, forces, options, and outcomes. This is the "decision trace" layer that Forrester identifies as the missing piece.
SHACL shapes encode governance principles as executable constraints — per-language validation (relationship validity, required properties) and organizational governance rules. Run via validate.sh in CI/CD.
Cross-language connectivity — nine modeling languages (ArchiMate, BPMN, UML, C4, Backstage, EDGY, LeanIX, BMC, BPMN-Lite) and ten governance frameworks (TOGAF, DoDAF, UAF, ADMIT, TIME, Zachman, EA on a Page, ATAM, 4+1, Platform Design) all share arch:core, enabling cross-domain reasoning.
SPARQL queryability makes the knowledge traversable — not just by humans reading diagrams, but by AI agents constructing answers via the MCP server.
Inference and consequence — OWL reasoning classifies instances (type subsumption, TIME quadrant assignment via owl:equivalentClass). SPARQL property paths traverse realization chains across layers. SHACL and SPARQL FILTER NOT EXISTS identify single points of failure and missing governance. All three engines converge on the same graph, each contributing what the others cannot.

Summary¶

Dimension	Architectural Data	Architectural Knowledge
Answers	What exists	Why it exists, what it means, what to do
Structure	Flat or weakly typed	Semantically rich, typed, inferrable
Source	Tools, discovery, manual entry	Architects' interpretation, decisions, experience
Durability	Perishable (decays with change)	Durable (principles and rationale outlive systems)
AI utility	Retrieval (search, lookup)	Reasoning (impact analysis, recommendations)
Governance	Completeness checks	Principle validation, decision consistency
Formalization	Spreadsheets, catalogs, models	Knowledge graphs, decision records, SHACL rules
Example	"App X uses Java 11"	"App X uses Java 11 because the 2023 platform decision mandated JVM-based runtimes for the payment domain due to library maturity for PCI-DSS compliance"

The gap between data and knowledge is the gap between an architecture repository that produces reports and one that supports decisions. Closing it requires deliberate formalization: typed relationships, decision records, encoded principles, and cross-domain connectivity.

Most organizations have the data. Few have formalized the knowledge. The ones that do are the ones whose enterprise architecture practices scale — to more stakeholders, to AI agents, to governance automation, and to the complexity that modern enterprises demand.

Architecture knowledge management isn't a new discipline — it's what experienced architects have always done. The new part is making it explicit, machine-readable, and queryable. That's what an architectural knowledge graph provides.

References¶

Foundational concepts¶

Nonaka, I. & Takeuchi, H. (1995). The Knowledge-Creating Company. Oxford University Press. — The tacit/explicit knowledge distinction applied to organizations
Ackoff, R.L. (1989). "From Data to Wisdom." Journal of Applied Systems Analysis, 16, 3–9. — The DIKW hierarchy
Kruchten, P., Lago, P., & van Vliet, H. (2006). "Building Up and Reasoning About Architectural Knowledge." QoSA 2006, LNCS 4214. — Foundational paper on architectural knowledge management

Architecture knowledge management¶

Jansen, A. & Bosch, J. (2005). "Software Architecture as a Set of Architectural Design Decisions." WICSA 2005. — Decisions as first-class architectural knowledge
Tang, A., Avgeriou, P., Jansen, A., Capilla, R., & Ali Babar, M. (2010). "A Comparative Study of Architecture Knowledge Management Tools." JSS, 83(3). — Survey of AKM approaches
Capilla, R., Jansen, A., Tang, A., Avgeriou, P., & Babar, M.A. (2016). "10 Years of Software Architecture Knowledge Management." JSS, 116, 191–205. — Decade retrospective

Industry analysis¶

Context Graphs Are a Convergence, Not an Invention — Forrester, Apr 2026. Entity graph + decision trace convergence.
The Dominant AI-Enabled IT Management Platforms Lean Into Context Graphs — Forrester, 2026
The New Architecture Mandate: Insights from Gartner IOC 2025 — EA Principals Journal
5 Things Enterprise Architects Are Doing Wrong — Timo Elliott (summarizing Gartner 2025)
Siemens STAR — Enterprise Knowledge Graphs in Software Engineering — Springer, 2018

Linked.Archi documentation¶

What is Linked.Archi? — Project overview, modules, and design principles
Enterprise Ontologies and the AI Context Problem — The analyst convergence on enterprise ontologies
Bridging Architecture Silos — Model once, view everywhere
Architecture & Approach — Core thesis and technical architecture