Skip to content

Knowledge on Another Level: OKF and Linked.Archi

One word, two very different meanings

In the current wave of AI tooling, "knowledge" has become one of the most overloaded words in the industry. It is used for the markdown files you drop into an agent's context window, for the documents behind a retrieval pipeline, for a wiki, for a CMDB export, and — in Linked.Archi's case — for a formally typed, machine-traversable graph that a reasoner can draw conclusions from. These are not the same thing, and treating them as interchangeable leads to disappointment: teams expect an agent fed a folder of markdown to reason about their architecture, when all it can actually do is retrieve passages from it.

Google Cloud's Open Knowledge Format (OKF), published as a v0.1 draft in mid-2026, is a clean, deliberate example of the first meaning: knowledge as portable markdown for humans and agents. Linked.Archi occupies the second: knowledge as formal semantic structure that OWL, SPARQL, and SHACL can operate on. This article compares the two honestly. Are they doing the same thing? Can they work together? Is Linked.Archi an evolution of the OKF idea, or only worth the extra formality in some cases?

The short answer: they solve adjacent problems at different rungs of the same ladder, they compose well, and neither replaces the other. The longer answer is worth the read, because the choice between them is one many architecture teams will face directly.

What OKF actually is

OKF is a vendor-neutral, intentionally minimal format for representing knowledge as plain markdown files with YAML frontmatter. Its design philosophy is that knowledge should be readable by humans without tooling, parseable by agents without a bespoke SDK, diffable in version control, and portable across tools and organizations. If you can read a file, you can read OKF; if you can clone a repository, you can ship it. Content was rephrased for compliance with the source's licensing.

The structural model is small:

  • A bundle is a directory tree of markdown files — the unit of distribution.
  • A concept is a single markdown document describing one unit of knowledge: a table, an API, a metric, a playbook, or an abstract idea.
  • Frontmatter carries metadata. Exactly one field is required — type, a short, self-describing string like BigQuery Table or Playbook. Recommended fields include title, description, resource (a canonical URI for the underlying asset), tags, and timestamp. Producers may add any keys they like.
  • Links are ordinary markdown links between concepts. Reserved files index.md (progressive-disclosure directory listing) and log.md (change history) have defined meaning.

A minimal concept looks like this:

---
type: BigQuery Table
title: Customer Orders
description: One row per completed customer order across all channels.
resource: https://console.cloud.google.com/bigquery?p=acme&d=sales&t=orders
tags: [sales, orders, revenue]
timestamp: 2026-05-28T14:30:00Z
---

# Schema

| Column        | Type    | Description                                         |
|---------------|---------|-----------------------------------------------------|
| `order_id`    | STRING  | Globally unique order identifier.                   |
| `customer_id` | STRING  | Foreign key into [customers](/tables/customers.md). |

Three properties of OKF matter most for the comparison that follows:

  1. Type values are not registered anywhere. There is no schema registry and no central authority. Consumers must tolerate unknown types, unknown keys, missing fields, and even broken links, treating them as "not yet written" rather than errors. This permissive, soft-conformance model is deliberate.
  2. Links are untyped. A link from concept A to concept B asserts that a relationship exists; what kind of relationship (depends-on, realizes, joins-with, supersedes) lives in the surrounding prose, not in the link. Consumers that build a graph treat every link as a directed edge of an unnamed relationship.
  3. It references domain schemas rather than subsuming them. OKF explicitly does not try to replace Avro, Protobuf, OpenAPI, or any domain-specific model. It points at them.

OKF is, in essence, a specified version of the markdown-plus-frontmatter knowledge base pattern that Obsidian, Notion, and "LLM wiki" repositories already use — pinning down just enough convention to make a corpus self-describing and portable, without dictating tooling.

What Linked.Archi means by knowledge

Linked.Archi uses "knowledge" in a stricter, more demanding sense. The distinction it draws between architectural data and architectural knowledge is not about file format — it is about whether meaning has been made explicit and machine-processable. Recording that an application exists is data. Understanding why it exists, what it serves, what breaks if it changes, and what should replace it is knowledge.

Linked.Archi frames this with the Data–Information–Knowledge–Wisdom (DIKW) progression and, crucially, insists that the transitions between rungs are performed by specific semantic engines rather than by better prose:

  • Data → Information is performed by SKOS taxonomies (a shared, hierarchical vocabulary) and OWL type declarations (every element gets a formal type). A cell reading "CRM" becomes a typed, classified, labelled entity.
  • Information → Knowledge is performed by the three engines reading one typed graph. OWL classifies under the open-world assumption ("what kind of thing is this?"). SPARQL traverses relationship chains under the closed-world assumption ("what does this ultimately connect to?"). SHACL validates and enables negation-based reasoning — "this is a single point of failure because no other component realizes the service" — a conclusion OWL cannot draw.
  • Knowledge → Wisdom is performed by the architecture-decisions extension (ad:), which makes rationale a first-class graph entity, and by governance SHACL shapes that encode principles as executable rules.

The load-bearing detail is typed relationships. am:realizes is not a label — it is an owl:ObjectProperty with documented semantics, which is exactly what lets a query traverse a realization chain or a validator detect a broken one. Meaning lives in the model, not in a human reader's interpretation of prose.

That single design choice is where OKF and Linked.Archi diverge most sharply.

Are they doing the same thing?

No. They optimize for opposite things, and the difference is clearest when mapped onto DIKW.

OKF is a superb Information-layer format. It gives knowledge structure (frontmatter, sections, tables), a shared-enough vocabulary (the type field, tags), controlled identity (resource URIs), and cross-references (markdown links). That is precisely the Data → Information transition Linked.Archi attributes to taxonomies and type declarations. An OKF bundle is structured, portable, human-readable, and agent-readable — genuinely more than a pile of documents.

But OKF stops, by design, exactly where Linked.Archi's definition of knowledge begins. Its relationships are untyped, its types are unregistered strings, and it prescribes no reasoning, query, or validation engine. An agent consuming an OKF bundle retrieves and reads; it does not infer, traverse, or validate. In DIKW terms, OKF is an excellent carrier for Data and Information and a convenient carrier for prose that humans will interpret as knowledge — but it does not itself perform the Information → Knowledge transition. That transition needs machine-processable meaning, and OKF deliberately leaves meaning in the prose.

Dimension OKF Linked.Archi
Primary purpose Portable, agent-readable knowledge capture and exchange Formal reasoning, governance, and cross-domain inference
DIKW reach Data → Information (knowledge-as-prose for humans/agents) Information → Knowledge → Wisdom (machine-traversable)
Relationships Untyped markdown links; kind lives in prose Typed properties (am:realizes, am:serves, …) with formal semantics
Types Unregistered self-describing strings OWL classes with subsumption and inference
Vocabulary tags, free type values SKOS taxonomies with broader/narrower
Validation None (soft conformance; broken links tolerated) SHACL shapes; violations block merges in CI/CD
Reasoning None (retrieval only) OWL classification, SPARQL traversal, SHACL negation
Infrastructure None — files, git, a text editor Triple store / SPARQL engine / SHACL validator
AI grounding style Retrieval grounding (context, RAG, progressive disclosure) Reasoning grounding (traversal, inference, impact analysis)
Barrier to entry Near zero Meaningful — requires modelling and semantic tooling

The row that matters most is the last-but-one. Both formats feed AI agents, but in different ways. Give an agent an OKF bundle and it becomes a well-organized search over your knowledge. Give an agent a Linked.Archi graph and it can answer "what breaks if we decommission Platform Y?" — a question that requires following typed chains and reasoning about the absence of alternatives, not just finding the right paragraph. That is the AI grounding distinction Linked.Archi draws between a search engine and an architecture advisor.

A matrix mapping the four DIKW levels against what OKF and Linked.Archi each provide: OKF carries data and structures information, but leaves knowledge in prose; Linked.Archi types information and performs the knowledge and wisdom transitions OKF and Linked.Archi cover overlapping but different rungs of the DIKW ladder. OKF is strong up to Information and carries knowledge as prose; Linked.Archi performs the Information → Knowledge → Wisdom transitions that need machine-processable meaning.

A worked example: one scenario, two representations

Abstract comparison only goes so far. Here is a single, small scenario represented fully in both formats, followed by the queries and validation the graph makes possible and the bridges that connect the two.

The scenario. A CRM System (an application component) realizes a Customer Management Service, which in turn supports the Customer Onboarding capability. The CRM System is owned by Team Sales. An architecture decision records that the CRM should be migrated, because it is the sole realization of a strategic capability and carries high technical debt.

The same scenario shown side by side: an OKF bundle of four markdown concept files connected by untyped markdown links, and a Linked.Archi RDF graph of the same four entities connected by typed relationships am:realizes and bs:ownedBy The identical scenario in both formats. The structure is the same; the difference is that OKF's links are untyped edges (the kind lives in prose) while the graph's edges are typed properties a machine can traverse and validate.

Representation A — the OKF bundle

The bundle is a directory of markdown concept files. Every file has frontmatter with a required type, and concepts link to each other with bundle-relative markdown links.

onboarding-bundle/
├── index.md
├── applications/
│   └── crm-system.md
├── services/
│   └── customer-management.md
├── capabilities/
│   └── customer-onboarding.md
├── teams/
│   └── team-sales.md
└── decisions/
    └── adr-089-crm-migration.md

The root index.md provides progressive disclosure (no frontmatter, per the spec):

# Applications
* [CRM System](/applications/crm-system.md) - Core CRM application component.

# Capabilities
* [Customer Onboarding](/capabilities/customer-onboarding.md) - Strategic onboarding capability.

# Decisions
* [ADR-089: Migrate the CRM](/decisions/adr-089-crm-migration.md) - Replace the CRM within 18 months.

applications/crm-system.md:

---
type: ApplicationComponent
title: CRM System
description: Core CRM application component; sole realization of Customer Management.
resource: https://model.example.com/crm-system
tags: [application-layer, customer, migrate]
timestamp: 2026-07-10T09:00:00Z
---

The CRM System realizes the [Customer Management Service](/services/customer-management.md)
and is owned by [Team Sales](/teams/team-sales.md). It is the only component that provides
customer management, which makes it a single point of failure for
[Customer Onboarding](/capabilities/customer-onboarding.md).

services/customer-management.md:

---
type: ApplicationService
title: Customer Management Service
description: Application service that supports the Customer Onboarding capability.
resource: https://model.example.com/customer-mgmt-service
tags: [application-layer, customer]
timestamp: 2026-07-10T09:00:00Z
---

Realized by the [CRM System](/applications/crm-system.md); supports the
[Customer Onboarding](/capabilities/customer-onboarding.md) capability.

capabilities/customer-onboarding.md:

---
type: Capability
title: Customer Onboarding
description: Strategic capability for onboarding new customers.
resource: https://model.example.com/customer-onboarding-cap
tags: [strategy, customer, strategic]
timestamp: 2026-07-10T09:00:00Z
---

Supported by the [Customer Management Service](/services/customer-management.md).

decisions/adr-089-crm-migration.md:

---
type: Decision
title: "ADR-089: Migrate the CRM System"
description: Replace the CRM within 18 months due to single-provider risk and technical debt.
resource: https://model.example.com/decision-089
tags: [adr, migration, customer]
timestamp: 2026-07-12T15:30:00Z
---

# Context

The [CRM System](/applications/crm-system.md) is the only realization of the
[Customer Management Service](/services/customer-management.md), which supports the
strategic [Customer Onboarding](/capabilities/customer-onboarding.md) capability. Its
technical-debt score is 7/10.

# Decision

Migrate to a cloud-native CRM within 18 months.

# Consequences

Removes single-provider risk for a strategic capability. Supersedes ADR-042.

This bundle is genuinely useful: a human can read it, an agent can retrieve from it, and it ships in git with no infrastructure. But notice what an agent cannot reliably derive from it: that the CRM is a single point of failure is stated in prose in crm-system.md, not computed. Change the estate — add a second component that realizes the service — and the prose is silently wrong until a human rewrites it. The links say that things relate; only the sentences say how.

Representation B — the Linked.Archi graph

The same scenario as typed RDF. Every relationship is a property with formal semantics.

@prefix am:   <https://meta.linked.archi/archimate3/onto#> .
@prefix bs:   <https://meta.linked.archi/backstage/onto#> .
@prefix ad:   <https://meta.linked.archi/arch-decision#> .
@prefix arch: <https://meta.linked.archi/core#> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
@prefix ex:   <https://model.example.com/onboarding#> .

ex:crm-system a am:ApplicationComponent ;
    skos:prefLabel "CRM System"@en ;
    bs:ownedBy     ex:team-sales ;
    am:realizes    ex:customer-mgmt-service .

ex:customer-mgmt-service a am:ApplicationService ;
    skos:prefLabel "Customer Management Service"@en ;
    am:realizes    ex:customer-onboarding-cap .

ex:customer-onboarding-cap a am:Capability ;
    skos:prefLabel "Customer Onboarding"@en .

ex:team-sales a bs:Group ;
    skos:prefLabel "Team Sales"@en .

ex:decision-089 a ad:Decision ;
    skos:prefLabel     "ADR-089: Migrate the CRM System"@en ;
    ad:problemStatement "CRM is the sole realization of a strategic capability and has high technical debt."@en ;
    ad:justification    "Single-provider risk for a strategic capability plus high tech debt makes it unsuitable for the target state."@en ;
    ad:affectsConcept   ex:crm-system ;
    ad:relatedConcept   ex:customer-onboarding-cap ;
    ad:replaces         ex:decision-042 .

What the graph answers that the bundle cannot

Because the relationships are typed, an engine can compute the facts that the OKF bundle could only assert in prose.

Which capabilities does the CRM ultimately support? A SPARQL property path follows the realization chain of any length — no hand-written traversal:

PREFIX am:   <https://meta.linked.archi/archimate3/onto#>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>

SELECT ?capabilityLabel WHERE {
  <https://model.example.com/onboarding#crm-system> am:realizes+ ?cap .
  ?cap a am:Capability ;
       skos:prefLabel ?capabilityLabel .
}
# → "Customer Onboarding"

Is the CRM a single point of failure? This is a closed-world, negation-dependent question — true only if no other component realizes the service. SPARQL answers it directly:

PREFIX am: <https://meta.linked.archi/archimate3/onto#>
PREFIX ex: <https://model.example.com/onboarding#>

ASK {
  ex:crm-system am:realizes ?service .
  FILTER NOT EXISTS {
    ?other am:realizes ?service .
    FILTER(?other != ex:crm-system)
  }
}
# → true  (recomputed automatically whenever the graph changes)

Governance as an executable rule. A SHACL shape turns the principle "a component that is the sole realization of a strategic capability must have a mitigation decision" into a check that runs on every commit:

@prefix sh:   <http://www.w3.org/ns/shacl#> .
@prefix am:   <https://meta.linked.archi/archimate3/onto#> .
@prefix ad:   <https://meta.linked.archi/arch-decision#> .
@prefix ex:   <https://model.example.com/onboarding#> .

ex:SoleProviderNeedsDecisionShape a sh:NodeShape ;
    sh:targetClass am:ApplicationComponent ;
    sh:sparql [
        sh:message "Sole realization of a strategic capability has no mitigation decision." ;
        sh:severity sh:Warning ;
        sh:select """
            SELECT $this WHERE {
              $this am:realizes/am:realizes ?cap .
              ?cap a am:Capability .
              FILTER NOT EXISTS { ?other am:realizes ?svc . ?svc am:realizes ?cap . FILTER(?other != $this) }
              FILTER NOT EXISTS { ?d a ad:Decision ; ad:affectsConcept $this . }
            }
        """ ;
    ] .

None of these three capabilities — chain traversal, negation-based detection, executable governance — is available over the OKF bundle, because OKF deliberately stops at structured information. This is the Information → Knowledge boundary made concrete.

The bridge, both directions

The two representations are not rivals; each can be generated from or lifted into the other.

Generate OKF from the graph (projection). The graph is authoritative; the OKF bundle above can be produced from it mechanically:

Graph (source of truth) OKF concept (generated)
a am:ApplicationComponent type: ApplicationComponent
skos:prefLabel "CRM System"@en title: CRM System
the entity IRI resource: https://…/crm-system
SKOS taxonomy terms tags: [application-layer, migrate]
am:realizes ex:customer-mgmt-service [Customer Management](/services/customer-management.md)

The projection is mildly lossy — am:realizes flattens to an untyped markdown link — but for retrieval and progressive disclosure that is exactly enough.

Lift OKF into the graph (capture). The reverse maps frontmatter to triples: type → OWL class, resource → IRI, tags → SKOS concepts. The one step that needs help is the relationship-typing gap — OKF links carry no type, so lifting [Customer Management](…) into am:realizes requires either an author-supplied hint or a human-confirmed inference. That gap is not a defect; it is the visible seam between the Information rung and the Knowledge rung.

Can they work together?

Yes — and this is the most useful conclusion, because it means the choice is not either/or. The worked example already showed the mechanics; the strategic picture is that the two formats sit at adjacent rungs and each feeds the other in a continuous loop.

A round-trip flow: an author writes low-friction OKF concepts that are lifted into the typed graph, the authoritative graph is projected back into OKF bundles for portable distribution, OKF feeds retrieval agents, and the graph grounds reasoning agents; the relationship-typing gap is highlighted as the lossy step in the lift OKF as the low-friction capture and distribution layer; the graph as the reasoning and governance core. The only lossy step is the relationship-typing gap on the lift.

OKF as a generated view of the graph

Linked.Archi's knowledge-sharing model is "generate, don't copy": the graph is authoritative, and stakeholder views are projected from it on demand. As the worked example's projection table showed, an OKF bundle is a natural such view — a portable, git-shippable, human-and-agent-readable knowledge base that any OKF-aware tool can consume without a triple store. The projection loses typed relationships and OWL/SHACL semantics, but for retrieval and progressive disclosure that is acceptable, and the graph remains the source of truth for anything that needs reasoning. This is the Share stage of the knowledge lifecycle done properly: one source, many rendered views.

OKF as a low-friction capture layer that lifts into the graph

The reverse direction is just as valuable. OKF's near-zero authoring cost makes it an excellent capture format — architects and engineers write markdown concepts as part of their normal workflow, exactly the lightweight capture Linked.Archi's lifecycle recommends. Those bundles lift into RDF as shown above, with the relationship-typing gap as the one step that needs an author hint or a human-confirmed inference. That gap is not a flaw in either format — it is the seam between the Information rung and the Knowledge rung, made visible.

A pragmatic division of labour falls out of this:

  • Author knowledge in OKF where friction must stay low and the audience is broad.
  • Reason and govern over the high-value subset that has been lifted into the graph.
  • Publish OKF bundles generated from the graph for wide, tooling-light distribution.

Is Linked.Archi an evolution of OKF, or only sometimes worth it?

Neither format is an evolution of the other — they were designed at roughly the same time for genuinely different problems, and OKF's minimalism is a feature, not an unfinished draft of something more formal. It is more accurate to say Linked.Archi operates at another level of the same DIKW ladder: it pays a higher formality-and-infrastructure cost to buy capabilities OKF explicitly declines to provide.

That framing turns "which is better?" into the more useful "which rung does this job need?"

Reach for OKF when:

  • The goal is capturing, exchanging, and retrieving knowledge with minimal ceremony.
  • The consumers are humans and retrieval-style agents (RAG, progressive disclosure).
  • Portability and zero infrastructure matter more than inference.
  • The knowledge is largely descriptive, and prose-level relationships are good enough.
  • You want knowledge to live in git next to code, diffable and reviewable.

Reach for Linked.Archi when:

  • You need to answer consequential questions — impact analysis, single-point-of-failure detection, "what depends on what across domains".
  • Governance must be automated and continuous — principles enforced as SHACL constraints in CI/CD, not PDFs nobody reads.
  • You need inference — automatic portfolio classification, subsumption, cross-notation federation of ArchiMate, TOGAF, BPMN, and Backstage into one queryable graph.
  • Decision rationale and its supersession history must be first-class and traversable.
  • You are grounding agents that must reason, not merely retrieve.

Most organizations will not choose once. The realistic trajectory is to start with OKF-style markdown knowledge because it is cheap and immediate, then promote the specific, high-value domains — the ones where an answer must be inferred and trusted rather than looked up — into the formal graph. OKF lowers the barrier to capturing knowledge at all; Linked.Archi raises the ceiling on what can be done with the knowledge that earns the investment. That is a complementary relationship, not a competitive one.

The deeper point, and the reason the word "knowledge" causes so much confusion: a folder of markdown fed to an agent and a validated, typed, reasoned-over graph are both legitimately called knowledge — but they are knowledge on different levels. Knowing which level a given job needs is the whole skill.

References

OKF

Linked.Archi