title: "Architectural Data vs Architectural Knowledge" description: "Most of what organizations call 'architectural knowledge' is actually data or information. True architecture knowledge requires formal semantic structure — ontologies, taxonomies, and validation rules — that enables AI agents, automated governance, and scalable decision-making." author: "Linked.Archi" date: 2026-05-23 image:

assets/diagrams/guide/foundations/architectural-data-vs-architectural-knowledge/data-to-knowledge-overview.svg
assets/diagrams/guide/foundations/architectural-data-vs-architectural-knowledge/dikw-progression.svg
assets/diagrams/guide/foundations/architectural-data-vs-architectural-knowledge/dikw-with-assets.svg
assets/diagrams/guide/foundations/architectural-data-vs-architectural-knowledge/linked-archi-transitions.svg
assets/diagrams/guide/foundations/architectural-data-vs-architectural-knowledge/semantic-assets-map.svg
assets/diagrams/guide/foundations/architectural-data-vs-architectural-knowledge/ask-the-architect.svg
assets/diagrams/guide/foundations/architectural-data-vs-architectural-knowledge/ai-grounding.svg
assets/diagrams/guide/foundations/architectural-data-vs-architectural-knowledge/five-transformations.svg
assets/diagrams/guide/foundations/architectural-data-vs-architectural-knowledge/data-spectrum.svg
assets/diagrams/guide/foundations/architectural-data-vs-architectural-knowledge/linked-archi-architecture.svg tags: [architectural-knowledge, architectural-data, knowledge-graph, enterprise-architecture, ontology, dikw, architecture-knowledge-management, semantic-architecture, ArchiMate-ontology, enterprise-ontology] mainEntity: "https://meta.linked.archi/core#" about:
"https://meta.linked.archi/core#"
"https://meta.linked.archi/arch-decision#"
"https://www.w3.org/OWL/"

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¶

The distinction 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:

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

Each transition is performed by a specific type of semantic asset. The ontology is the engine that converts structured information into machine-traversable knowledge. Most EA repositories stop at the Information level — they have typed elements and named relationships, but lack the formal semantics that enable inference and reasoning.

The DIKW lens — and the role of semantic assets¶

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 assets. Taxonomies, ontologies, and validation shapes are the formal scaffolding that elevates raw data into machine-traversable knowledge.

The DIKW hierarchy with the semantic assets that drive each transition — taxonomies classify, ontologies connect, experience generalizes.

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 ontology with formal semantics enables inference; SHACL shapes validate completeness
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 precisely where ontologies earn their keep — they are the formal scaffolding that turns "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.

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.

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: OWL ontologies with formal semantics¶

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, but the system can't reason about what that means. It can't infer that removing App-042 would eliminate the capability, or that App-042 is therefore a critical dependency.

What Linked.Archi provides:

OWL ontologies with formal semantics define what relationships mean. am:realizes isn't just a label — it's an owl:ObjectProperty with defined domain, range, and semantic implications. A reasoner can traverse realization chains: if App-042 realizes Service-X, and Service-X realizes Capability-Y, then App-042 is a provider of Capability-Y.
SHACL shapes (*-shapes.ttl files) enforce structural constraints that make the graph trustworthy. Before data enters the knowledge graph, SHACL validates that it conforms to the metamodel — correct relationship types, required properties, valid cardinalities. Without this, your "knowledge" graph fills with garbage that silently breaks inference.
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-21 for the full rationale.

Concrete example:

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 .
                    ↓ apply OWL inference + SHACL validation
Knowledge:   # Inferred: ex:crm-system is a provider of ex:customer-onboarding-cap
             # Inferred: if no other component realizes ex:customer-mgmt-service,
             #           then ex:crm-system is a SINGLE POINT OF FAILURE for that capability
             # Validated: SHACL confirms the realization chain is complete and well-formed

The typed relationships now support reasoning. A SPARQL query can answer "what capabilities are at risk if we decommission the CRM?" — not because someone wrote that answer down, but because the ontology's formal semantics allow the machine to derive it. This is the moment data becomes knowledge: when the ontology makes meaning explicit enough for machines to reason over it.

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	Formal class/property definitions, inference rules, semantic relationships	`archimate-onto.ttl`, `core-onto.ttl`
SHACL Shapes	Guards Knowledge quality	Validates data before it enters the graph; encodes governance rules	`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: an ontology is the engine that converts information into knowledge. 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 machines the ability to reason about realization chains. When you define that am:ApplicationComponent rdfs:subClassOf arch:Element, you've made classification explicit. When you add a SHACL shape that requires every component to have an owner, you've encoded a governance principle as executable knowledge.

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 support inference — logical reasoning that derives new facts from existing ones. If A realizes B and B realizes C, then removing A impacts C. This is knowledge encoded in structure, not in someone's memory.

In technical terms: an ArchiMate ontology expressed in RDF/OWL gives relationships formal semantics that a reasoner can traverse, 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.

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 (OWL reasoning) derives new knowledge from existing facts — if A realizes B and B is classified as critical, then A is a critical dependency. The TIME framework uses OWL equivalent classes for automatic quadrant classification.

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 Formal Architecture and Practical Adoption — Model once, view everywhere
Architecture & Approach — Core thesis and technical architecture