diff --git a/.github/workflows/docs.yml b/.github/workflows/docs.yml
index d55bc753..e9336889 100644
--- a/.github/workflows/docs.yml
+++ b/.github/workflows/docs.yml
@@ -7,44 +7,40 @@ on:
pull_request:
workflow_dispatch:
-env:
- HOMEBREW_NO_INSTALL_CLEANUP: 1
-
jobs:
build:
- runs-on: macos-latest
+ runs-on: ubuntu-latest
steps:
-# -
-# name: Install some tools
-# run: sudo apt-get install -y libcairo2-dev libfreetype6-dev libffi-dev libjpeg-dev libpng-dev libz-dev
-# -
-# name: Set up Homebrew
-# id: set-up-homebrew
-# uses: Homebrew/actions/setup-homebrew@master
- -
- name: Install Python
- uses: actions/setup-python@v5
- with:
- python-version: '3.13'
-
name: Set up Git repository
uses: actions/checkout@v4
with:
fetch-depth: 0
-
- name: Cache asdf installations
- uses: actions/cache@v4
+ name: Install system dependencies
+ run: |
+ sudo apt-get update
+ sudo apt-get install -y \
+ libcairo2-dev \
+ libpango1.0-dev \
+ libfreetype6-dev \
+ libffi-dev \
+ libjpeg-dev \
+ libpng-dev \
+ zlib1g-dev \
+ graphviz \
+ libgraphviz-dev
+ -
+ name: Install Python
+ uses: actions/setup-python@v5
with:
- path: |
- ~/.asdf/installs
- ~/.asdf/plugins
- ~/.asdf/shims
- key: ${{ runner.os }}-asdf-${{ hashFiles('.tool-versions') }}
- restore-keys: |
- ${{ runner.os }}-asdf-
+ python-version: '3.14'
+ -
+ name: Install uv
+ run: pip install uv
-
name: Cache uv dependencies
- uses: actions/cache@v4
+ uses: actions/cache@v5
with:
path: |
~/.cache/uv
@@ -52,14 +48,9 @@ jobs:
key: ${{ runner.os }}-uv-${{ hashFiles('uv.lock', 'pyproject.toml') }}
restore-keys: |
${{ runner.os }}-uv-
- -
- name: Install asdf & tools
- uses: asdf-vm/actions/install@v4
-
name: Install all MkDocs dependencies
- run: |
- # echo "/home/linuxbrew/.linuxbrew/bin/brew" >> $GITHUB_PATH
- make --environment-overrides docs-install-github-actions
+ run: make --environment-overrides docs-install-github-actions
-
name: Build Site
# Build runs on all branches and PRs to validate changes
diff --git a/.gitignore b/.gitignore
index e1bf98eb..8ee2049b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -59,3 +59,4 @@ out/
*.xdy
.venv/
.pdm-python
+Screenshot*
diff --git a/.markdownlint.json b/.markdownlint.json
new file mode 100644
index 00000000..ffa81762
--- /dev/null
+++ b/.markdownlint.json
@@ -0,0 +1,11 @@
+{
+ "MD013": {
+ "line_length": 140,
+ "heading_line_length": 140,
+ "code_block_line_length": 140
+ },
+ "MD025": {
+ "front_matter_title": ""
+ }
+}
+
diff --git a/.python-version b/.python-version
new file mode 100644
index 00000000..1d5dadf3
--- /dev/null
+++ b/.python-version
@@ -0,0 +1,2 @@
+3.14.2
+
diff --git a/.vscode/settings.json b/.vscode/settings.json
index a49ee134..4c28511c 100644
--- a/.vscode/settings.json
+++ b/.vscode/settings.json
@@ -1,3 +1,10 @@
{
- "makefile.configureOnOpen": false
+ "yaml.schemas": {
+ "https://squidfunk.github.io/mkdocs-material/schema.json": "mkdocs.yml"
+ },
+ "yaml.customTags": [
+ "tag:yaml.org,2002:python/name",
+ "tag:yaml.org,2002:python/object/apply"
+ ],
+ "makefile.configureOnOpen": false
}
diff --git a/Makefile b/Makefile
index 2d00e27b..7bd77530 100644
--- a/Makefile
+++ b/Makefile
@@ -23,15 +23,14 @@ endif
endif
#
-# Since we do not have asdf for Windows, we need to install these tools
-# on windows in a different way. Here we assume you did that yourself in
-# the local project's virtualenv directory (./.venv).
+# Windows note: install the required build tools separately (outside of this Makefile),
+# then run `make install` to create/use the local project's virtualenv (./.venv).
#
VENV_PYTHON := $(VIRTUAL_ENV)/bin/python3
UV := uv
-PYTHON_VERSION := 3.13
+PYTHON_VERSION := 3.14.2
-PIPENV_DEFAULT_PYTHON_VERSION := 3.13
+PIPENV_DEFAULT_PYTHON_VERSION := 3.14.2
PIPENV_VENV_IN_PROJECT := 1
CURRENT_BRANCH := $(shell git branch --show-current)
@@ -69,6 +68,10 @@ docs-install: docs-install-brew docs-install-brew-packages docs-install-python-p
docs-install-github-actions: docs-install-brew-packages docs-install-python-packages info
.PHONY: docs-install-brew-packages
+ifeq ($(YOUR_OS), Linux)
+docs-install-brew-packages:
+ @echo "Skip Homebrew packages on Linux (installed via apt-get in CI)"
+else
docs-install-brew-packages:
@echo "Install packages via HomeBrew:"
@brew upgrade cairo 2>/dev/null || brew install cairo
@@ -80,6 +83,7 @@ docs-install-brew-packages:
@brew upgrade zlib 2>/dev/null || brew install zlib
@brew upgrade graphviz 2>/dev/null || brew install graphviz
@brew upgrade uv 2>/dev/null || brew install uv
+endif
.PHONY: docs-install-brew
ifeq ($(YOUR_OS), Linux)
@@ -110,25 +114,8 @@ docs-install-brew-macos:
@if ! command -v brew >/dev/null 2>&1 ; then echo "Install HomeBrew" ; exit 1 ; fi
@brew --version
-.PHONY: docs-install-asdf
-docs-install-asdf: docs-install-brew
- @echo "Install the asdf package manager:"
- @if ! command -v asdf >/dev/null 2>&1; then \
- brew upgrade asdf 2>/dev/null || brew install asdf; \
- fi
- @asdf plugin add python 2>/dev/null || true
-
-.PHONY: docs-install-asdf-packages
-docs-install-asdf-packages: docs-install-asdf
- @echo "Install packages via asdf:"
- asdf install
-
.PHONY: docs-install-python-packages
-#ifneq ($(wildcard /home/runner/.*),)
-#docs-install-python-packages: docs-install-asdf
-#else
-docs-install-python-packages: docs-install-asdf-packages docs-install-standard-python-packages
-#endif
+docs-install-python-packages: docs-install-standard-python-packages
.PHONY: docs-install-standard-python-packages
docs-install-standard-python-packages: docs-ensure-venv
@@ -183,7 +170,7 @@ docs-serve-debug-non-strict: docs-ensure-venv
.PHONY: docs-deploy
docs-deploy: docs-ensure-venv
- $(UV) run mkdocs gh-deploy --config-file $(MKDOCS_CONFIG_FILE) --verbose
+ $(UV) run mkdocs gh-deploy --config-file $(MKDOCS_CONFIG_FILE)
.PHONY: docs-sync-from
docs-sync-from: docs-sync-from-ekg-maturity docs-sync-from-ekg-principles
diff --git a/README.md b/README.md
index d0e92d32..e2997772 100644
--- a/README.md
+++ b/README.md
@@ -2,9 +2,17 @@
Documenting the Use Case Tree method.
+## Python
+
+This repo uses **Python 3.13+** (see `pyproject.toml`) and **uv**.
+
+```bash
+uv sync
+```
+
This is an initiative of:
-- agnos.ai UK Ltd
-- Enterprise Knowledge Graph Foundation
+- [agnos.ai UK Ltd](https://agnos.ai)
+- [Object Management Group](https://omg.org) (OMG) [Enterprise Knowledge Graph Forum](https://ekgf.org) (EKGF)
The content of this repository is published as https://method.ekgf.org
diff --git a/docs-overrides/main.html b/docs-overrides/main.html
index 5c661a1d..8250c67f 100644
--- a/docs-overrides/main.html
+++ b/docs-overrides/main.html
@@ -1,5 +1,11 @@
{% extends "base.html" %}
+
+{% block extrahead %}
+{{ super() }}
+{% include "partials/seo.html" %}
+{% endblock %}
+
{% block content %}
{% if page.meta.generated == True %}
diff --git a/docs-overrides/partials/seo.html b/docs-overrides/partials/seo.html
new file mode 100644
index 00000000..e88f0cda
--- /dev/null
+++ b/docs-overrides/partials/seo.html
@@ -0,0 +1,92 @@
+{# SEO Meta Tags Partial #}
+
+{# Get page-specific description or fall back to site description #}
+{% set page_description = page.meta.description if page.meta and page.meta.description else config.site_description %}
+
+{# Get page title #}
+{% set page_title = page.title if page.title else config.site_name %}
+{% set full_title = page_title + " - " + config.site_name if page_title != config.site_name else config.site_name %}
+
+{# Get page URL #}
+{# Prefer MkDocs' canonical_url when available #}
+{% set page_url = page.canonical_url if page.canonical_url else (config.site_url + page.url if page.url else config.site_url) %}
+
+{# Get page image (use site logo or custom image) #}
+{% set page_image = config.site_url + "/assets/images/favicon.png" %}
+{% if page.meta and page.meta.image %}
+ {% set page_image = config.site_url + page.meta.image if page.meta.image.startswith("/") else page.meta.image %}
+{% endif %}
+
+{# Open Graph / Facebook #}
+
+
+
+
+
+
+{% if config.site_author %}
+
+{% endif %}
+
+{# Twitter Card #}
+
+
+
+
+
+{% if config.extra.social %}
+ {% for social in config.extra.social %}
+ {% if "twitter" in social.link %}
+
+ {% endif %}
+ {% endfor %}
+{% endif %}
+
+{# Additional SEO meta tags #}
+{% if page.meta and page.meta.keywords %}
+
+{% endif %}
+
+{# Google Search Console verification #}
+{% if config.extra.google_site_verification %}
+
+{% endif %}
+
+{# JSON-LD Structured Data #}
+
+
diff --git a/docs/assets/dikw-revised.svg b/docs/assets/dikw-revised.svg
new file mode 100644
index 00000000..be993821
--- /dev/null
+++ b/docs/assets/dikw-revised.svg
@@ -0,0 +1,674 @@
+
\ No newline at end of file
diff --git a/docs/concept/.pages.yaml b/docs/concept/.pages.yaml
index e96dd235..de3f5676 100644
--- a/docs/concept/.pages.yaml
+++ b/docs/concept/.pages.yaml
@@ -5,6 +5,7 @@ nav:
- persona.md
- story.md
- concept.md
+ - term.md
- outcome.md
- data-product.md
- ontology.md
diff --git a/docs/concept/concept.md b/docs/concept/concept.md
index 1d7e2baa..808b9f03 100644
--- a/docs/concept/concept.md
+++ b/docs/concept/concept.md
@@ -1,27 +1,277 @@
+---
+description: "A domain term or idea that links business language to semantic models, enabling the Enterprise Knowledge Graph to understand and reason about business concepts. Learn how concepts bridge business and technical domains in the Use Case Tree Method."
+keywords:
+ - concept
+ - domain concept
+ - business concept
+ - semantic model
+ - EKG method
+ - enterprise knowledge graph
+schema_type: "Article"
+---
+
# Concept
-For every given Use Case we want to start with capturing the concepts and
-terms that the user or "the business" uses or wants to use.
-
-Most of these concepts and their terms will be pre-defined in all kinds of
-vocabularies but for brand-new use cases in a new domain concepts and their
-terms will have to be created.
-
-At the initial stages of a use case, the focus should be on capturing the
-language of the users in their domain, which may not necessarily involve
-discussing ontologies.
-The main goal is to gather requirements and understand the problem context,
-as well as the terms and concepts used by the users.
-Later in the use case's life cycle, once the problem is well understood,
-the relevant ontologies can be mapped to the terms and concepts captured earlier.
-This allows for better integration of the use case with the overall EKG ecosystem.
-
-As the use case evolves and the understanding of the domain becomes clearer,
-it may be necessary to adjust the captured concepts and terms to better
-reflect the reality of the domain.
-, it may be necessary to map the captured concepts and terms to more appropriate
-terms in a specific ontology or vocabulary to ensure consistency and interoperability
-across the enterprise.
-In either case, the important thing is to ensure that the captured concepts and
-terms accurately reflect the reality of the domain and the needs of the stakeholders.
+
+_A domain term or idea that links business language to semantic models,
+enabling the Enterprise Knowledge Graph to understand and reason about
+business concepts_
+
+
+=== "Business & Management Audience"
+
+ ## What Is a Concept?
+
+ For every given [Use Case](use-case.md), we want to start with
+ capturing the concepts and terms that the user or "the business"
+ uses or wants to use.
+
+ A **Concept** is a way to represent a business idea or term in a
+ way that both humans and machines can understand.
+ It serves as a bridge between the language your organization uses
+ and the formal semantic models (ontologies) that enable the
+ Enterprise Knowledge Graph to reason about your business.
+
+ ## Why Concepts Matter
+
+ Concepts ensure that:
+
+ - **Business language is preserved** — We capture terms as the
+ business uses them, not as some external standard defines them
+ - **Semantic meaning is enabled** — Concepts link to ontologies
+ that give them machine-readable meaning
+ - **Consistency is maintained** — The same concept can be reused
+ across multiple use cases
+ - **Interoperability is achieved** — Concepts can map to
+ multiple ontologies, enabling integration across systems
+
+ !!! tip "Start with business language"
+
+ Don't worry about ontologies in the early stages.
+ Focus on capturing what the business calls things and what
+ those things mean in their context.
+
+ ## Concept Vocabulary
+
+ Most concepts and their terms will be pre-defined in all kinds of
+ vocabularies, but for brand-new use cases in a new domain,
+ concepts and their terms will have to be created.
+
+ Each Use Case can have its own vocabulary of concepts, but it can
+ also inherit or borrow concepts from higher-level or related use
+ cases in the [Use Case Tree](use-case-tree.md).
+ This enables reuse and consistency across the enterprise.
+
+ ## Evolution and Refinement
+
+ As the use case evolves and the understanding of the domain
+ becomes clearer, it may be necessary to:
+
+ - **Adjust concepts** — Better reflect the reality of the domain
+ - **Map to ontologies** — Link concepts to more appropriate
+ terms in specific ontologies or vocabularies to ensure
+ consistency and interoperability across the enterprise
+
+ In either case, the important thing is to ensure that the
+ captured concepts and terms accurately reflect the reality of the
+ domain and the needs of the stakeholders.
+
+=== "Data & Tech Audience"
+
+ ## What Is a Concept in the Use Case Tree Method?
+
+ A **Concept** is the linking pin between local business language
+ and formal semantic models (ontologies).
+ It enables the EKG to understand business terminology while
+ maintaining connections to standardized vocabularies and enabling
+ automated reasoning.
+
+ ## The Concept Lifecycle
+
+ ### Initial Capture
+
+ At the initial stages of a use case, the focus should be on
+ capturing the language of the users in their domain, which may not
+ necessarily involve discussing ontologies.
+ The main goal is to gather requirements and understand the
+ problem context, as well as the terms and concepts used by the
+ users.
+
+ !!! tip "Business-first approach"
+
+ Start with what the business calls things, not what some
+ ontology says they should be called.
+ The business owns its use cases and should recognize them
+ throughout their lifecycle.
+
+ ### Mapping to Ontologies
+
+ Later in the use case's lifecycle, once the problem is well
+ understood, the relevant ontologies can be mapped to the terms and
+ concepts captured earlier.
+ This allows for better integration of the use case with the
+ overall EKG ecosystem.
+
+ ### Refinement and Evolution
+
+ As the use case evolves and the understanding of the domain
+ becomes clearer, it may be necessary to:
+
+ - **Adjust captured concepts** — Better reflect the reality of
+ the domain
+ - **Map to appropriate ontologies** — Link to more appropriate
+ terms in specific ontologies or vocabularies to ensure
+ consistency and interoperability across the enterprise
+
+ ## Concept Types
+
+ Concepts can represent different types of semantic elements:
+
+ - **Class Concepts** — Represent types or categories (e.g.,
+ "Person", "Account", "Transaction")
+ - **Property Concepts** — Represent relationships or attributes
+ (e.g., "hasOwner", "isLocatedIn", "hasValue")
+ - **Shape Concepts** — Represent validation constraints or data
+ shapes
+
+ ## Concepts as Linking Pins
+
+ Concepts are the linking pin in many ways.
+ They link "business terms" and "technical terms" as they are
+ used in the context of the given use case, by the business and
+ by various programs, apps, and systems, in all their variations
+ and manifestations.
+
+ **Example:**
+ The official term for Customer could be "Customer," but it
+ appears in different forms:
+ - On forms in apps as "Cust."
+ - In Python code as `_customer`
+ - In SPARQL statements as `?cust`
+ - In database schemas as `cust_id` or `customer_id`
+ - In API endpoints as `/customers` or `/api/cust`
+ - In OWL ontologies as specific axioms (e.g., `owl:Class` or
+ `rdfs:subClassOf` relationships)
+ - In SHACL shapes as validation constraints (e.g., `sh:property`
+ or `sh:minCount`)
+
+ All these symbols, terms, axioms, and shapes are manifestations
+ of the same concept and linked to it.
+ Even the mapping to certain axioms in an OWL ontology or
+ certain shapes in a SHACL shape would be seen as "technical
+ terms" — just yet some other manifestations of a given concept.
+
+ This enables the EKG to understand that these different
+ representations all refer to the same business concept, enabling
+ semantic integration across diverse systems and technologies.
+
+ ## Relationship to Ontologies
+
+ Concepts serve as a bridge between:
+
+ - **Local business terminology** — The language used within a
+ specific use case or domain
+ - **Technical manifestations** — How concepts appear in code,
+ databases, APIs, forms, and other systems
+ - **Standard ontologies** — Formal semantic models that enable
+ interoperability and reasoning
+
+ This multi-faceted nature allows the EKG to:
+ - Address "the business" with their language
+ - Integrate with technical systems using their terminology
+ - Keep backend EKG models generic and linked to appropriate
+ ontologies
+ - Model semantic conundrums (e.g., different terms for the same
+ concept, same term for different concepts)
+
+ ## Reuse and Inheritance
+
+ Concepts follow the same reuse patterns as other elements in the
+ Use Case Tree Method:
+
+ - **Local definition** — Each use case can define concepts
+ specific to its domain
+ - **Inheritance** — Lower-level use cases inherit concepts from
+ parent use cases in the Use Case Tree
+ - **Borrowing** — Use cases can reference concepts from related
+ use cases
+ - **Consistency** — Common concepts are defined once and reused
+
+ This ensures that concepts are not duplicated unnecessarily and
+ that the EKG maintains semantic consistency across the enterprise.
+
+ ## Relationship to Other Concepts
+
+ Concepts are fundamental building blocks that relate to:
+
+ - **[Use Cases](use-case.md)** — Each use case has a vocabulary
+ of concepts
+ - **[Personas](persona.md)** — Personas are Concepts, enabling
+ semantic definition and reasoning
+ - **[Stories](story.md)** — Stories reference domain concepts
+ that need to be understood and modeled
+ - **[Ontologies](ontology.md)** — Concepts link to ontology
+ classes, properties, and shapes
+
+=== "Ontology"
+
+ ## Ontology (minimal facts we can state today)
+
+ --8<-- "fragment/uctm-diagram-concept.md"
+
+ We're not (yet) prescribing a full OWL ontology here.
+ But we can state a small set of **facts** that people can reliably use to build their own
+ ontology / schema / graph model around a Concept.
+
+ ### Required facts about a Concept
+
+ - **Opaque universally unique identifier**
+ - A Concept must have an **opaque**, **universally unique** identifier.
+ - Prefer a random identifier such as **UUIDv4**.
+ - Represent it as a URI, for example:
+ `urn:uuid:550e8400-e29b-41d4-a716-446655440000`
+
+ - **Slug**
+ - A Concept should have a kebab-cased slug.
+ - Slug uniqueness cannot be guaranteed, but it can be used as a convenient alternative
+ identifier next to the real identifier (with lookup/search).
+ - Do **not** use the slug as a foreign key in the Knowledge Graph itself; use the real
+ identifier for references.
+
+ - **Label Term (instead of a traditional label)**
+ - A Concept does not have a traditional label such as `skos:prefLabel` or `rdfs:label`.
+ - Instead, it has a **labelTerm** link to one of its **BusinessTerm** objects (a resource
+ in the Knowledge Graph).
+ - Learn more in [Term](term.md).
+
+ - **Definition**
+ - A Concept must have a business-focused definition explaining what it means in context.
+
+ - **One or more Terms (required)**
+ - A Concept must have **one or more Terms** (`Term`), which can be either a
+ **BusinessTerm** or a **TechnicalTerm**.
+ - A Concept without a Term has no reason to exist.
+ - All Terms of a Concept **mean the same thing** in the context of that Concept.
+ - Terms may include alternative spellings, abbreviations, synonyms, and technical
+ manifestations.
+ - Terms are **owned** by the Concept (part-of): when the Concept is deleted, its Term
+ objects are deleted as well.
+ - Learn more in [Term](term.md).
+
+ - **Contained in a Concept Vocabulary**
+ - A Concept is a member of a Concept Vocabulary (a “container” of Concepts).
+ - A Use Case can relate to Concept Vocabularies via relationship-objects:
+ - it can **reference** an external vocabulary and/or
+ - **own** a private vocabulary.
+
+ - **Mapping to ontologies (optional)**
+ - A Concept can be mapped/aligned to terms in one or more ontologies (classes,
+ properties, shapes).
+ - Model this via mapping/alignment relationships so you can capture confidence, rationale,
+ and provenance.
+
+ - **Used by Stories and Workflows**
+ - Stories use Concepts as **input**, **output**, and **dependent** concepts.
+ - Workflows use Concepts through the Stories they orchestrate and the vocabulary of the
+ Use Case.
diff --git a/docs/concept/data-product.md b/docs/concept/data-product.md
index 3faebaf2..2f27ce78 100644
--- a/docs/concept/data-product.md
+++ b/docs/concept/data-product.md
@@ -1,10 +1,319 @@
+---
+description: "A semantic data product that provides required information for a Use Case, selected based on semantic relevance and suitability. Learn how data products enable reuse in the Use Case Tree Method."
+keywords:
+ - data product
+ - semantic data product
+ - data asset
+ - EKG method
+ - enterprise knowledge graph
+ - data reuse
+schema_type: "Article"
+---
+
# Data Product
-In later stages of the use case life-cycle, we can attach the use case to those
-semantic data products that already exist and can provide the required information
-for the use case.
-However, it's important to note that the choice of semantic data products to
-be used for a given use case should be made based on their semantic relevance
-and suitability to the use case's requirements.
+
+_A semantic data product that provides required information for a Use
+Case, selected based on semantic relevance and suitability to the
+use case's requirements_
+
+
+=== "Business & Management Audience"
+
+ ## What Is a Data Product?
+
+ A **Data Product** is a semantic data asset that provides the
+ required information for a [Use Case](use-case.md).
+ In later stages of the use case lifecycle, we can attach the use
+ case to those semantic data products that already exist and can
+ provide the required information.
+
+ Data Products are reusable components that encapsulate data,
+ along with its meaning (semantics), making it available for use
+ across multiple use cases.
+
+ ## The Data Economy
+
+ Think of your entire data landscape or ecosystem as a **data
+ economy** — like any economy, it has a supply side and a demand
+ side.
+
+ - **Supply side** — Data Products define what data is available,
+ how it's packaged, and how it can be accessed.
+ They represent the "supply" in the data economy.
+ - **Demand side** — [Use Cases](use-case.md) define who needs
+ data, what they need it for, and why.
+ They represent the "demand" in the data economy.
+
+ People often understand Data Products (the supply side), but
+ struggle with "what's the demand?"
+ Who uses these data products, and for what reasons?
+ That's where Use Cases come in: a Use Case defines the demand
+ side, specifying what data is needed and why.
+
+ This economic model helps organizations understand the flow of
+ data, identify gaps between supply and demand, and ensure that
+ data products are created to meet actual business needs.
+
+ ## Why Data Products Matter
+
+ Data Products enable:
+
+ - **Reuse** — Data can be packaged once and reused across
+ multiple use cases
+ - **Consistency** — The same data product ensures consistent
+ meaning and structure across use cases
+ - **Efficiency** — Avoids duplicating data preparation and
+ transformation work
+ - **Quality** — Data products are designed, tested, and
+ maintained as reusable assets
+
+ !!! tip "Semantic relevance matters"
+
+ The choice of data products for a use case should be based
+ on their semantic relevance and suitability to the use case's
+ requirements, not just technical availability.
+
+ ## When Are Data Products Used?
+
+ Data Products are typically identified and attached to use cases
+ in later stages of the lifecycle, once:
+
+ - The use case requirements are well understood
+ - The data needs are clearly defined
+ - Existing data products can be evaluated for suitability
+
+ This allows use cases to leverage existing, proven data products
+ rather than creating new ones from scratch.
+
+=== "Data & Tech Audience"
+
+ ## What Is a Data Product in the Use Case Tree Method?
+
+ A **Data Product** is a semantic data asset that provides
+ required information for a [Use Case](use-case.md).
+ It encapsulates data along with its semantic meaning (defined
+ through [Ontologies](ontology.md)), making it a reusable
+ component in the Enterprise Knowledge Graph.
+
+ ## Semantic Data Products
+
+ Data Products in the Use Case Tree Method are **semantic** — they include:
+
+ - **Data** — The actual data values
+ - **Semantics** — The meaning of the data, defined through
+ ontologies
+ - **Structure** — How the data is organized
+ - **Metadata** — Information about the data product itself
+
+ This semantic nature enables the EKG to understand what the data
+ means, not just what it contains.
+
+ ## Selection Criteria
+
+ The choice of semantic data products to be used for a given use
+ case should be made based on:
+
+ - **Semantic relevance** — Does the data product contain
+ concepts and terms that match the use case's vocabulary?
+ - **Suitability** — Does the data product meet the use case's
+ requirements?
+ - **Quality** — Is the data product well-maintained and
+ reliable?
+ - **Availability** — Is the data product accessible and
+ performant?
+
+ !!! tip "Semantic matching"
+
+ The most important criterion is semantic relevance — the
+ data product should align with the use case's concepts and
+ terminology, enabling semantic integration.
+
+ ## Lifecycle Integration
+
+ In later stages of the use case lifecycle, we can attach the use
+ case to those semantic data products that already exist and can
+ provide the required information.
+
+ This approach:
+
+ - **Promotes reuse** — Leverages existing data products rather
+ than creating new ones
+ - **Ensures consistency** — Multiple use cases can use the same
+ data product, ensuring consistent data
+ - **Reduces effort** — Avoids duplicating data preparation work
+ - **Maintains quality** — Uses proven, tested data products
+
+ ## Relationship to Other Concepts
+
+ Data Products relate to other core concepts:
+
+ - **[Use Cases](use-case.md)** — Use cases consume data
+ products to fulfill their requirements
+ - **[Ontologies](ontology.md)** — Data products use ontologies
+ to define the semantic meaning of their data
+ - **[Concepts](concept.md)** — Data products contain data about
+ concepts that are relevant to use cases
+ - **[Stories](story.md)** — Stories may require specific data
+ products to fulfill their needs
+
+ This integration ensures that data products are not isolated
+ assets but part of a cohesive, semantic model of the enterprise.
+
+ ## Reuse and Composition
+
+ Data Products are designed for reuse across multiple use cases.
+ This enables:
+
+ - **Composition** — Use cases can combine multiple data products
+ to meet their requirements
+ - **Consistency** — The same data product ensures consistent
+ meaning across use cases
+ - **Efficiency** — Data preparation is done once and reused
+ many times
+ - **Maintainability** — Changes to a data product benefit all
+ use cases that use it
+
+ This reuse pattern aligns with the [composable
+ business](../objective/composable-business.md) approach, where
+ data products become reusable components in the Enterprise
+ Knowledge Graph.
+
+=== "DPROD Ontology"
+
+ ## What Is DPROD?
+
+ The **Data Product Ontology (DPROD)** is a specification developed
+ by the Object Management Group (OMG) Enterprise Knowledge Graph Forum (EKGF) that provides
+ a standardized way to describe Data Products using W3C Linked Data
+ standards.
+ DPROD is available at
+ [https://ekgf.github.io/dprod/](https://ekgf.github.io/dprod/).
+
+ DPROD builds on the W3C Data Catalog Vocabulary (DCAT) to enable
+ publishers to describe Data Products and data services in a
+ decentralized way.
+ By using a standard model and ontology, DPROD facilitates the
+ consumption and aggregation of metadata from multiple Data
+ Marketplaces, increasing discoverability and enabling federated
+ search.
+
+ ## Why DPROD?
+
+ As organizations increasingly recognize the value of data as an
+ asset and adopt decentralized data architectures (such as Data
+ Mesh), the need for standardized methods to describe and manage
+ data products consistently across platforms has become critical.
+
+ Without such a standard, organizations face:
+ - Inconsistent metadata across diverse data products
+ - Limited discoverability
+ - Interoperability issues that hinder data integration
+ - Difficulty scaling as data ecosystems grow
+ - Increased vendor lock-in
+
+ DPROD offers a solution by providing a clear schema for describing
+ data products, ensuring they are discoverable, interoperable,
+ and treated with the same level of accountability as traditional
+ products.
+
+ ## DPROD Principles
+
+ DPROD follows two basic principles:
+
+ - **Decentralize Data Ownership** — To make data integration
+ more efficient, tasks should be shared among multiple teams.
+ DCAT helps by offering a standard way to publish datasets in a
+ decentralized manner.
+ - **Harmonize Data Schemas** — Using shared schemas helps unify
+ different data formats.
+ DPROD provides a common set of rules for defining a Data
+ Product, which users can extend as needed.
+
+ ## DPROD Model
+
+ The DPROD specification extends DCAT to connect Data Services to
+ Data Products using input and output ports.
+ These ports are used to publish and consume data from a Data
+ Product.
+
+ The model consists of:
+
+ - **Data Product** (`dprod:DataProduct`) — A rational, managed,
+ and governed collection of data, with purpose, value, and
+ ownership, meeting consumer needs over a planned lifecycle
+ - **Port** (`dcat:DataService`) — A digital interface that
+ provides access to a Dataset (input or output port)
+ - **Distribution** (`dcat:Distribution`) — A specific
+ representation of a dataset (CSV, JSON, Parquet, etc.) which
+ can conform to a physical model
+ - **Dataset** (`dcat:Dataset`) — A collection of related data
+ that can conform to a logical model
+
+ Data Products can have:
+ - **Input ports** — Services that collect source data and make
+ it available for transformation
+ - **Output ports** — Services that share generated data in a way
+ that can be understood and trusted
+ - **Lifecycle status** — Development status (e.g., Ideation,
+ Design, Build, Deploy, Consume)
+ - **Owner** — The agent accountable for the data product
+ - **Domain** — The business or information area supported
+ - **Purpose** — Objectives and intended usage
+
+ ## Relationship to Use Case Tree Method
+
+ DPROD provides a standardized way to describe Data Products that
+ aligns with the Use Case Tree Method's approach:
+
+ - **Semantic description** — DPROD uses ontologies to describe
+ the semantic meaning of data products
+ - **Reuse and composition** — DPROD enables data products to be
+ discovered and composed
+ - **Lifecycle management** — DPROD tracks the lifecycle status
+ of data products
+ - **Decentralized architecture** — DPROD supports decentralized
+ data ownership and management
+
+ When implementing Data Products in the Use Case Tree Method, DPROD can be
+ used to provide standardized metadata that enables discovery,
+ integration, and governance across the enterprise.
+
+ ## Key Features
+
+ DPROD enables:
+
+ - **Unambiguous semantics** — Provides clear, sharable semantics
+ to answer "What is a data product?"
+ - **Simplicity and expressiveness** — Simple enough for anyone
+ to use, but expressive enough to power large data marketplaces
+ - **Reuse of existing infrastructure** — Allows organizations to
+ reuse their existing data catalogues and dataset infrastructure
+ - **Harmonization** — Shares common semantics across different
+ Data Products, promoting consistency
+
+ For more details, examples, and the complete specification, see
+ the [DPROD documentation](https://ekgf.github.io/dprod/).
+
+ !!! important "Data Products as Use Cases"
+
+ A **Data Product is basically just another Use Case** — with
+ its own stereotype.
+ You can stereotype a use case as a "data-product" or as an
+ "upstream data-source" or "downstream data-sink," or whatever
+ categorization you prefer.
+ But fundamentally, a data product can be seen as just another
+ use case.
+
+ This unified model means that:
+ - Data Products follow the same lifecycle as Use Cases
+ - They can be organized in the [Use Case
+ Tree](use-case-tree.md)
+ - They have the same components: Personas, Stories, Concepts,
+ Outcomes
+ - They enable the same composability and reuse patterns
+
+ The stereotype simply indicates the primary purpose or role of
+ that use case in the data economy.
diff --git a/docs/concept/ontology.md b/docs/concept/ontology.md
index 7dda4c53..1df5c1d8 100644
--- a/docs/concept/ontology.md
+++ b/docs/concept/ontology.md
@@ -1,16 +1,195 @@
+---
+description: "A formal, machine-readable specification of concepts and their relationships that bridges the gap between demand (Use Cases) and supply (Data Products). Learn how ontologies enable semantic interoperability in the Use Case Tree Method."
+keywords:
+ - ontology
+ - semantic model
+ - knowledge representation
+ - EKG method
+ - enterprise knowledge graph
+ - data modeling
+schema_type: "Article"
+---
+
# Ontology
-The ontologies act as a crucial intermediary between the demand and supply sides
-of the information economy.
+
+_A formal, machine-readable specification of concepts and their
+relationships that bridges the gap between demand (Use Cases) and
+supply (Data Products) in the data economy_
+
+
+=== "Business & Management Audience"
+
+ ## What Is an Ontology?
+
+ An **Ontology** is a formal specification of concepts and their
+ relationships that provides a common language for describing
+ business knowledge.
+ In the context of the Enterprise Knowledge Graph, ontologies act
+ as a crucial intermediary between the demand and supply sides of
+ the information economy.
+
+ ## The Role of Ontologies in the Data Economy
+
+ Think of the data economy as having two sides:
+
+ - **Demand side** — [Use Cases](use-case.md) represent the
+ demands for information from various stakeholders.
+ They define what data is needed and why.
+ - **Supply side** — [Data Products](data-product.md) represent
+ the supply of information.
+ They define what data is available and how it can be accessed.
+
+ **Ontologies bridge the gap** between these two sides by
+ providing a common language that can be used to describe the
+ [Concepts](concept.md) and relationships relevant to both the
+ demand and supply sides.
+
+ !!! tip "Common language"
+
+ Ontologies enable use cases and data products to "speak the
+ same language," making it possible to match what's needed with
+ what's available.
+
+ ## Why Ontologies Matter
+
+ Ontologies enable:
+
+ - **Semantic integration** — Different systems can understand
+ each other's data because they share the same semantic model
+ - **Reuse** — Concepts defined once in an ontology can be reused
+ across multiple use cases and data products
+ - **Consistency** — Ensures that the same concept means the same
+ thing everywhere
+ - **Automated reasoning** — Machines can understand and reason
+ about business concepts
+ - **Interoperability** — Enables integration across diverse
+ systems and technologies
+
+ This enables a more efficient and effective exchange of
+ information, allowing organizations to better leverage their data
+ assets and achieve their business objectives.
+
+=== "Data & Tech Audience"
+
+ ## What Is an Ontology in the Use Case Tree Method?
+
+ An **Ontology** is a formal, machine-readable specification of
+ concepts and their relationships, typically expressed using
+ standards like OWL (Web Ontology Language) or SHACL (Shapes
+ Constraint Language).
+
+ In the Use Case Tree Method, ontologies serve as the semantic foundation
+ that enables the Enterprise Knowledge Graph to understand and
+ reason about business concepts.
+
+ ## Ontologies as Intermediaries
+
+ Ontologies act as a crucial intermediary between the demand and
+ supply sides of the information economy:
+
+ - **Demand side** — [Use Cases](use-case.md) represent the
+ demands for information from various stakeholders.
+ They define what data is needed and why.
+ - **Supply side** — [Data Products](data-product.md) represent
+ the supply of information.
+ They define what data is available and how it can be accessed.
+
+ The ontologies help bridge the gap between these two sides by
+ providing a common language that can be used to describe the
+ concepts and relationships relevant to both the demand and supply
+ sides.
+
+ ## How Ontologies Bridge the Gap
+
+ Ontologies enable semantic matching between use cases and data
+ products:
+
+ 1. **Use Cases define concepts** — Each use case has a
+ vocabulary of [Concepts](concept.md) that represent the
+ domain knowledge it needs
+ 2. **Concepts link to ontologies** — Concepts are linked to
+ ontology classes, properties, and shapes that define their
+ semantic meaning
+ 3. **Data Products conform to ontologies** — Data products
+ specify which ontologies their datasets conform to
+ 4. **Semantic matching** — The EKG can match use cases to data
+ products based on shared ontology concepts
+
+ This semantic matching enables the EKG to automatically discover
+ which data products can fulfill the requirements of a given use
+ case.
+
+ ## Ontology Standards
+
+ Ontologies in the Use Case Tree Method typically use:
+
+ - **OWL (Web Ontology Language)** — For defining classes,
+ properties, and relationships with rich logical expressivity
+ - **SHACL (Shapes Constraint Language)** — For defining
+ validation constraints and data shapes
+ - **RDFS (RDF Schema)** — For basic class and property
+ hierarchies
+
+ These standards enable:
+
+ - **Machine readability** — Ontologies can be processed by
+ automated systems
+ - **Reasoning** — Automated reasoners can infer new knowledge
+ from ontology definitions
+ - **Validation** — Data can be validated against ontology
+ constraints
+ - **Interoperability** — Different systems can share and reuse
+ ontology definitions
+
+ ## Relationship to Concepts
+
+ [Concepts](concept.md) serve as the linking pin between business
+ language and ontologies:
+
+ - **Business language** — Concepts capture the terms and ideas
+ that the business uses
+ - **Ontology mapping** — Concepts link to ontology classes,
+ properties, and shapes that define their semantic meaning
+ - **Multiple mappings** — A single concept can map to multiple
+ ontologies, enabling integration across different standards
+
+ This dual nature allows the EKG to address "the business" with
+ their language while maintaining formal semantic models that
+ enable automated reasoning and integration.
+
+ ## Reuse and Standardization
+
+ Ontologies enable reuse and standardization:
+
+ - **Standard ontologies** — Organizations can use existing
+ standard ontologies (e.g., FIBO, CDM, schema.org) rather than
+ creating everything from scratch
+ - **Domain ontologies** — Domain-specific ontologies can be
+ created and reused across use cases in the same domain
+ - **Extension** — Standard ontologies can be extended to meet
+ specific organizational needs
+ - **Composition** — Multiple ontologies can be combined to
+ create comprehensive semantic models
+
+ This reuse ensures consistency across the enterprise and enables
+ interoperability with external systems and standards.
+
+ ## Relationship to Other Concepts
+
+ Ontologies relate to other core concepts:
-On one hand, we have the use cases that represent the demands for information
-from various stakeholders, and on the other hand, we have the semantic data products
-that represent the supply of information.
+ - **[Concepts](concept.md)** — Concepts link to ontology
+ classes, properties, and shapes to define their semantic
+ meaning
+ - **[Use Cases](use-case.md)** — Use cases have vocabularies of
+ concepts that link to ontologies
+ - **[Data Products](data-product.md)** — Data products specify
+ which ontologies their datasets conform to
+ - **[Personas](persona.md)** — Personas are Concepts that link
+ to ontology classes, enabling semantic definition
-The ontologies help bridge the gap between these two sides by providing a common
-language that can be used to describe the concepts and relationships relevant to
-both the demand and supply sides.
-This enables a more efficient and effective exchange of information,
-allowing organizations to better leverage their data assets and achieve
-their business objectives.
+ This integration ensures that ontologies are not isolated
+ specifications but part of a cohesive, semantic model of the
+ enterprise.
diff --git a/docs/concept/outcome.md b/docs/concept/outcome.md
index 5426451c..10af3d68 100644
--- a/docs/concept/outcome.md
+++ b/docs/concept/outcome.md
@@ -1,13 +1,256 @@
+---
+description: "The specific result or benefit that an organization expects to achieve from a Use Case, providing the 'why' behind every business requirement. Learn how outcomes drive business value in the Use Case Tree Method."
+keywords:
+ - outcome
+ - business outcome
+ - use case outcome
+ - EKG method
+ - enterprise knowledge graph
+schema_type: "Article"
+---
+
# Outcome
-A business outcome is the specific result or benefit that an organization expects
-to achieve from a particular use case.
-It is the reason why the use case exists and what it aims to accomplish.
-Business outcomes can vary depending on the use case and the organization's goals,
-but they should always align with the broader strategy and objectives of the
-enterprise.
-Measuring and tracking business outcomes is essential for evaluating the effectiveness
-of a use case and its contribution to the overall success of the organization.
+
+_The specific result or benefit that an organization expects to achieve
+from a Use Case, providing the "why" behind every business requirement_
+
+
+=== "Business & Management Audience"
+
+ ## What Is an Outcome?
+
+ A **business outcome** is the specific result or benefit that an
+ organization expects to achieve from a particular [Use
+ Case](use-case.md).
+ It is the reason why the use case exists and what it aims to
+ accomplish.
+
+ Outcomes answer the fundamental question: **"Why are we doing
+ this?"**
+ They provide the business justification for investing time,
+ resources, and effort into a use case.
+
+ ## Why Outcomes Matter
+
+ Outcomes ensure that:
+
+ - **Purpose is clear** — Everyone understands why the use case
+ exists and what it's trying to achieve
+ - **Alignment is maintained** — Use cases contribute to broader
+ strategy and objectives
+ - **Success can be measured** — Outcomes provide criteria for
+ evaluating effectiveness
+ - **Value is demonstrated** — Clear outcomes show how use cases
+ contribute to organizational success
+
+ !!! tip "Start with outcomes"
+
+ Before defining what a use case does, understand why it
+ exists.
+ The outcome defines success and guides all decisions about
+ implementation.
+
+ ## Outcome Characteristics
+
+ Business outcomes can vary depending on the use case and the
+ organization's goals, but they should always:
+
+ - **Align with strategy** — Support the broader strategy and
+ objectives of the enterprise
+ - **Be measurable** — Provide clear criteria for success
+ - **Be achievable** — Realistic given available resources and
+ constraints
+ - **Be valuable** — Deliver meaningful benefit to the
+ organization
+
+ ## Examples
+
+ Examples of business outcomes include:
+
+ - **Risk Assessment** — "Assess the Risk" (from a risk
+ management use case)
+ - **Stakeholder Verification** — "Verify Stakeholders" (from an
+ audit use case)
+ - **Operational Efficiency** — "Reduce processing time by 50%"
+ - **Compliance** — "Ensure regulatory compliance"
+ - **Customer Satisfaction** — "Improve customer experience"
+
+ Notice how outcomes appear in [Stories](story.md) as the "why"
+ part: "...so that I can Assess the Risk" or "...so that I can
+ Verify Stakeholders."
+
+ ## Measuring Outcomes
+
+ Measuring and tracking business outcomes is essential for:
+
+ - **Evaluating effectiveness** — Understanding whether the use
+ case is achieving its intended results
+ - **Demonstrating value** — Showing how use cases contribute to
+ organizational success
+ - **Informing decisions** — Providing data for prioritization
+ and resource allocation
+ - **Continuous improvement** — Identifying opportunities to
+ enhance outcomes
+
+ Outcomes should be defined with measurable criteria from the
+ start, enabling ongoing evaluation throughout the use case's
+ lifecycle.
+
+=== "Data & Tech Audience"
+
+ ## What Is an Outcome in the Use Case Tree Method?
+
+ An **Outcome** represents the business value or benefit that a
+ [Use Case](use-case.md) is designed to deliver.
+ It is the "why" part of the [Story](story.md) structure: "As a
+ [Persona](persona.md), I need [capability], so that I can
+ [Outcome]."
+
+ Outcomes provide the business justification and success criteria
+ for use cases, enabling alignment between business needs and
+ technical implementation.
+
+ ## Outcome Structure
+
+ Outcomes are expressed in business language and typically follow
+ patterns like:
+
+ - **Action-oriented** — "Assess the Risk", "Verify Stakeholders"
+ - **Benefit-focused** — "Reduce processing time", "Improve
+ accuracy"
+ - **Value-driven** — "Increase revenue", "Ensure compliance"
+
+ The key is that outcomes are expressed in terms the business
+ understands and values, not in technical terms.
+
+ ## Outcome Stereotypes
+
+ We can define **Outcome Stereotypes** to categorize outcomes
+ based on their nature or purpose.
+ If you want to call an outcome a "Goal", "Objective", or
+ "Definition of Done", that's just a stereotype of Outcome.
+
+ Common outcome stereotypes include:
+
+ - **Goal** — A high-level, strategic outcome
+ - **Objective** — A specific, measurable outcome
+ - **Definition of Done** — A completion criterion for a use case
+ or story
+ - **Success Criteria** — Measurable conditions that indicate
+ success
+ - **Key Result** — A quantifiable outcome that supports a goal
+
+ These stereotypes help organize and categorize outcomes while
+ maintaining the fundamental concept that they all represent the
+ "why" behind business requirements.
+ The Use Case Tree Method uses "Outcome" as the base concept, with
+ stereotypes providing additional semantic meaning as needed.
+
+ ## Relationship to Stories
+
+ Outcomes are the "why" component of Stories.
+ Each Story specifies:
+
+ - **Who** — The Persona who needs the capability
+ - **What** — The capability or action needed
+ - **Why** — The Outcome (the business benefit or purpose)
+
+ This structure ensures that every requirement is tied to a clear
+ business outcome, preventing the implementation of features that
+ don't deliver value.
+
+ ## Alignment with Strategy
+
+ Outcomes should align with the broader strategy and objectives of
+ the enterprise.
+ This alignment ensures that:
+
+ - **Use cases contribute to strategic goals** — Each use case
+ delivers outcomes that support enterprise objectives
+ - **Resources are prioritized** — Use cases with outcomes that
+ align with strategy receive appropriate priority
+ - **Value is maximized** — The EKG delivers capabilities that
+ matter to the business
+
+ ## Measuring and Tracking
+
+ Outcomes should be defined with measurable criteria, enabling:
+
+ - **Quantitative measurement** — Metrics that can be tracked
+ and reported (e.g., "reduce processing time by 50%")
+ - **Qualitative assessment** — Evaluation of quality or
+ satisfaction (e.g., "improve customer experience")
+ - **Continuous monitoring** — Ongoing evaluation throughout the
+ use case lifecycle
+ - **Value demonstration** — Clear evidence of contribution to
+ organizational success
+
+ The EKG can track outcomes by linking them to metrics, KPIs, and
+ other measurement mechanisms, enabling automated reporting and
+ analysis.
+
+ ## Relationship to Other Concepts
+
+ Outcomes relate to other core concepts:
+
+ - **[Use Cases](use-case.md)** — Each use case has one or more
+ outcomes that define its purpose
+ - **[Stories](story.md)** — Stories specify outcomes as the
+ "why" component
+ - **[Personas](persona.md)** — Outcomes are achieved by
+ Personas through Stories
+ - **Strategy** — Outcomes align with enterprise strategy and
+ objectives
+
+ This integration ensures that outcomes are not abstract goals but
+ concrete, measurable results that drive the EKG's value
+ proposition.
+
+=== "Ontology"
+
+ ## Ontology (minimal facts we can state today)
+
+ --8<-- "fragment/uctm-diagram-outcome.md"
+
+ We're not (yet) prescribing a full OWL ontology here.
+ But we can state a small set of **facts** that people can reliably use to build their own
+ ontology / schema / graph model around an Outcome.
+
+ ### Required facts about an Outcome
+
+ - **Opaque universally unique identifier**
+ - An Outcome should have an **opaque**, **universally unique** identifier.
+ - Prefer a random identifier such as **UUIDv4**, represented as a URI:
+ `urn:uuid:550e8400-e29b-41d4-a716-446655440000`
+
+ - **Business-friendly name**
+ - An Outcome must have a human-readable name expressed in business language.
+
+ - **Definition**
+ - An Outcome must have a definition explaining the expected benefit/result.
+
+ - **Stereotype**
+ - An Outcome can have an **Outcome Stereotype** (e.g. KPI, Goal, Objective, Success
+ Criteria, Definition of Done).
+ - Stereotypes categorize outcomes without changing the underlying “Outcome” concept.
+
+ - **Time horizon (optional)**
+ - Outcomes often imply a time horizon (short/mid/long term). Capture it explicitly if
+ it matters.
+ - **Measurability (optional but recommended)**
+ - Outcomes should have measurable success criteria where possible (metrics, thresholds,
+ targets, baselines).
+ - **Owned by a Use Case (optional)**
+ - Outcomes are often defined/owned by a Use Case, but can be referenced by other Use
+ Cases (e.g., children).
+ - **Use Case ↔ Outcome relationship-object (recommended)**
+ - Model the connection between a Use Case and an Outcome via a **relationship-object**
+ (not just a direct link).
+ - This supports:
+ - **Inheritance**: a child Use Case referencing an Outcome defined on a parent Use Case
+ - **Contribution mapping**: describing *how* the child contributes to that desired Outcome
+ - **Local outcomes**: linking to Outcomes owned by the current Use Case as well
diff --git a/docs/concept/persona.md b/docs/concept/persona.md
index 7fc95556..7a61c66b 100644
--- a/docs/concept/persona.md
+++ b/docs/concept/persona.md
@@ -1,51 +1,255 @@
+---
+description: "A representation of the different types of players — people, systems, or entities — involved in a Use Case, defined using business language. Understand how personas shape requirements in the Use Case Tree Method."
+keywords:
+ - persona
+ - user persona
+ - stakeholder
+ - EKG method
+ - enterprise knowledge graph
+schema_type: "Article"
+---
+
# Persona
+
+_A representation of the different types of players — people, systems,
+or entities — involved in a Use Case, defined using business language_
+
+
=== "Business & Management Audience"
- For any given Use Case we need to have a list of all the different types of players.
- In the initial stages of the life cycle of a use case it is less relevant whether these players
- are called Stakeholders, Actors, Roles, User Types or Systems, we simply need to know what terms the
- actual users, the real customer(s) of the use case, are using for them in their daily practice.
+ ## What Is a Persona?
+
+ For any given [Use Case](use-case.md), we need to identify all
+ the different types of players involved.
+ In the initial stages of a use case's lifecycle, it matters less
+ whether these players are called Stakeholders, Actors, Roles, User
+ Types, or Systems.
+ What matters is understanding what terms the actual users — the
+ real customers of the use case — use for them in their daily
+ practice.
+
+ We call them **Personas**.
+
+ ## Why Personas Matter
+
+ Personas help us understand who interacts with a use case and
+ what their needs are.
+ They provide a common language that bridges business and
+ technology, ensuring that everyone understands who is involved
+ and what roles they play.
- We call them Personas.
+ !!! tip "Use business language"
- For example, in the use case "Legal Entity Management" you would have Personas like:
+ Start with the terms your organization already uses.
+ Don't force technical terminology — let the business
+ language guide you.
- - Auditor
- - Data Owner
- - Shareholder
- - Director
- - Signator
- - Signator Power Pursuent to Commercial Register
- - Board Member
- - Legal Council
- - Liquidator
+ ## Examples
+
+ For example, in the use case "Legal Entity Management," you
+ would have Personas like:
+
+ - **Auditor** — Reviews and verifies legal entity information
+ - **Data Owner** — Responsible for maintaining accurate data
+ - **Shareholder** — Has ownership interest in the entity
+ - **Director** — Member of the board of directors
+ - **Signator** — Authorized to sign on behalf of the entity
+ - Signator Power Pursuant to Commercial Register
+ - **Board Member** — Serves on the entity's board
+ - **Legal Council** — Provides legal guidance
+ - **Liquidator** — Manages entity dissolution
- ...
- Many of these Personas are involved in multiple use cases and are grouped together in _persona taxonomies_
- and defined in _ontologies_ with "machine readable meaning" that can be used to let algorithms "understand"
+ ## Reuse Across Use Cases
+
+ Many Personas are involved in multiple use cases and are
+ grouped together in **persona taxonomies**.
+ These taxonomies are defined in [ontologies](ontology.md) with
+ "machine-readable meaning" that enables algorithms to understand
the actual context and act upon it.
+ This reuse ensures consistency across the enterprise and enables
+ the [composable business](../objective/composable-business.md)
+ approach, where Personas become reusable components in the
+ Enterprise Knowledge Graph.
+
=== "Data & Tech Audience"
- In traditional use case modelling people use the term _Actor_ rather than _Persona_.
- The term _Actor_ is also used in a TOGAF Metamodel and combined with the term _Role_ whereby an actor
- assumes a role to perform a task.
+ ## Persona vs. Actor vs. Role
+
+ In traditional use case modeling, the term **Actor** is commonly
+ used rather than **Persona**.
+ The term Actor is also used in the TOGAF Metamodel, where it is
+ combined with the term **Role** — an actor assumes a role to
+ perform a task.
+
+ The Use Case Tree Method does not make that distinction, primarily to keep
+ things simple when capturing requirements — primarily as
+ [Stories](story.md) — but also because the term Persona combines
+ both concepts into one unified model.
+
+ ## Key Technical Characteristics
+
+ ### Automated Role Assignment
+
+ Actors assuming a Role is fully automated, context-dependent,
+ and driven by models, rules, and policies.
+ This means that the system determines which Persona applies
+ based on the current context, rather than requiring manual
+ assignment.
+
+ ### Real-Time Persona Computation
+
+ A proper EKG service layer is able to compute the set of
+ Personas that the current user has **in real-time** and map
+ them to lower-level roles and privileges local to the given
+ technology stack.
+
+ This dynamic computation enables:
+
+ - **Contextual assignment** — Some Personas are assigned to a
+ user temporarily, just in the context of a given use case or
+ when working with a specific object
+ - **Rule-based determination** — Personas can be computed
+ based on business rules (e.g., you can be the "Account
+ Owner" if the account is assigned to you, is in your region,
+ etc.)
+ - **Technology stack mapping** — The EKG service layer
+ translates high-level Personas into the specific roles and
+ privileges required by each technology stack (databases,
+ APIs, applications)
+
+ This approach ensures that authorization and access control are
+ driven by business semantics (Personas) rather than
+ technology-specific roles, while still respecting the
+ constraints and capabilities of each underlying system.
+
+ ### Ontology-Based Definition
+
+ Technically (or ontologically), a **Persona is just another
+ [Concept](concept.md)** — tied to ontology-defined classes that
+ can inherit from other Persona types.
+ This fundamental equivalence enables:
+
+ - **Inheritance relationships** — Personas can be organized in
+ hierarchies (e.g., "Signator Power Pursuant to Commercial
+ Register" is a sub-persona of "Signator")
+ - **Semantic meaning** — Personas have machine-readable
+ definitions that enable automated reasoning
+ - **Reuse** — Personas defined once can be used across multiple
+ use cases
+
+ ### Concept Vocabulary and Reuse
+
+ Each [Use Case](use-case.md) can have its own vocabulary of
+ concepts, including Personas.
+ However, use cases also **inherit or borrow** concepts from
+ higher-level or otherwise related use cases in the
+ [Use Case Tree](use-case-tree.md) (UCT).
+
+ This approach enables:
+
+ - **Local vocabulary** — Use cases can define concepts
+ (including Personas) specific to their domain
+ - **Inheritance** — Lower-level use cases inherit concepts from
+ their parent use cases in the UCT hierarchy
+ - **Borrowing** — Use cases can reference and reuse concepts
+ from related use cases, even if they're not direct ancestors
+ - **Consistency** — Common concepts (like standard Personas) are
+ defined once and reused, ensuring consistency across the
+ enterprise
+
+ Since Personas are Concepts, they follow the same reuse and
+ inheritance patterns as any other concept in the Use Case Tree Method.
+
+ ### Beyond Active Users
+
+ Personas are not just the "users" (or systems) of the use case
+ but also any other party in the related data models (or EKG
+ models/ontologies).
+
+ For instance, your user can have the Persona "Legal Entity
+ Maintainer," but since the legal entity can have a Director as
+ well, the Director is also a Persona, even when that Director
+ might never be an active user of the system.
+
+ This broader definition ensures that all entities involved in
+ the domain are properly represented, whether they actively
+ interact with the system or are simply part of the data model.
+
+ ## Relationship to Stories
+
+ [Stories](story.md) define what a Persona needs to accomplish.
+ Each Story specifies:
+
+ - **Who** — The Persona (e.g., "As an Auditor...")
+ - **What** — The action or need (e.g., "...I need to get a
+ list of all current board members...")
+ - **Why** — The business outcome (e.g., "...so that I can
+ Verify Stakeholders")
+
+ This structure links Personas to business requirements in a
+ clear, testable way.
+
+ ## Persona Inheritance
+
+ Personas support inheritance through the `isSubPersonaOf`
+ relationship.
+ This enables hierarchical organization where more specific
+ Personas inherit characteristics from more general ones.
+
+ **Example:**
+ - `Signator Power Pursuant to Commercial Register` is a
+ sub-persona of `Signator`
+ - A user associated with the sub-persona automatically inherits
+ the parent Persona's characteristics
+
+ **How it works:**
+ This inheritance works bottom-up: if a user is associated with
+ ``, and `` is a sub-persona of
+ ``, then the user is also associated with
+ ``.
+
+=== "Ontology"
+
+ ## Ontology (minimal facts we can state today)
+
+ --8<-- "fragment/uctm-diagram-persona.md"
+
+ We're not (yet) prescribing a full OWL ontology here.
+ But we can state a small set of **facts** that people can reliably use to build their own
+ ontology / schema / graph model around a Persona.
+
+ ### Required facts about a Persona
+
+ - **Opaque universally unique identifier**
+ - A Persona should have an **opaque**, **universally unique** identifier.
+ - Prefer a random identifier such as **UUIDv4**, represented as a URI:
+ `urn:uuid:550e8400-e29b-41d4-a716-446655440000`
- The Use Case Tree Method does not make that distinction, primarily to keep things as simple as possible when
- capturing requirements --- primarily as [stories](story.md) --- but also because the term Persona combines both
- concepts into one whereby:
+ - **Business-friendly name**
+ - A Persona must have a human-readable name (e.g., “Auditor”, “Chief Risk Officer”).
- - Actors assuming a Role is fully automated, context dependent, model-, rule- and policy-driven
- - Personas are [Concepts](concept.md) tied to Ontology-defined Classes that can inherit from other Persona types
- - Personas are not just the "users" (or systems) of the use case but also any other party in the related
- data-models (or EKG models/ontologies). For instance, your user can have the persona "Legal Entity Maintainer"
- but since the legal entity can have a Director as well, the Director is also a Persona, even when that
- Director might never be an active user of the system.
+ - **Slug**
+ - A Persona should have a kebab-cased slug (convenient identifier; do not use as a foreign
+ key in the Knowledge Graph).
+ - Example: `auditor`, `chief-risk-officer`, `legal-entity-maintainer`
+ - **Definition**
+ - A Persona should have a definition describing who it represents in the domain.
-=== "Model"
+ - **Persona inheritance (optional)**
+ - Personas can be related via `isSubPersonaOf` for hierarchical organization.
-A subset of the model, as a UML Class Diagram, around **Persona**.
+ - **Persona taxonomy membership (required)**
+ - Personas are `skos:Concept`.
+ - Every Persona is a member of exactly one **PersonaTaxonomy** (a `skos:ConceptScheme`)
+ via `skos:inScheme`.
+ - Each Use Case can have **zero or one PersonaTaxonomy** that provides the scheme for
+ Personas used in that Use Case.
-
+ - **Participation in Stories (relationship-object)**
+ - Stories reference Personas in the “Who” part.
+ - Model the connection via a relationship-object if you need to capture context such as
+ role, responsibility, entitlement, or provenance.
diff --git a/docs/concept/story.md b/docs/concept/story.md
index 87e4e0a2..c7ce7586 100644
--- a/docs/concept/story.md
+++ b/docs/concept/story.md
@@ -1,68 +1,254 @@
+---
+description: "A structured business requirement expressed in plain language that defines what a Persona needs to accomplish within a Use Case. Learn how stories capture requirements in the Use Case Tree Method."
+keywords:
+ - story
+ - user story
+ - business requirement
+ - persona story
+ - EKG method
+ - enterprise knowledge graph
+schema_type: "Article"
+---
+
# Story
+
+_A structured business requirement expressed in plain language that
+defines what a Persona needs to accomplish within a Use Case_
+
+
=== "Business & Management Audience"
- A Story --- in the context of a [Use Case](use-case.md) in the
- [Use Case Tree](use-case-tree.md) --- defines a business requirement.
-
- A business user could specify a requirement as follows:
-
- - _As the Chief Risk Officer, I need to know our current Risk Position against party B, so that I can Assess the Risk_
- - _As an Auditor, I need to get a list of all current board members of legal entity X, so that I can Verify Stakeholders_
- - _As an Employee, I need to get a list of all my colleagues in my unit, so that I Know my Colleagues_
- - _As a customer, I need to get a list of all products, so that I can make a product selection_
-
- And so forth. That's all we ask in the early phases of a given use case.
-
+ ## What Is a Story?
+
+ A **Story** — in the context of a [Use Case](use-case.md) in the
+ [Use Case Tree](use-case-tree.md) — defines a business
+ requirement.
+ It captures what someone needs to accomplish, expressed in their
+ own language.
+
+ ## Story Structure
+
+ Stories follow a simple, structured format that captures three
+ essential elements:
+
+ - **Who** — The [Persona](persona.md) who needs this capability
+ (e.g., "As the Chief Risk Officer...")
+ - **What** — What they need to do or know (e.g., "...I need to
+ know our current Risk Position...")
+ - **Why** — The business [Outcome](outcome.md) or purpose (e.g.,
+ "...so that I can Assess the Risk")
+
+ !!! tip "Start simple"
+
+ In the early phases of a use case, we only ask for these
+ three elements.
+ Don't worry about how it will be implemented — that comes
+ later.
+
+ ## Examples
+
+ A business user could specify requirements as follows:
+
+ - _As the Chief Risk Officer, I need to know our current Risk
+ Position against party B, so that I can Assess the Risk_
+ - _As an Auditor, I need to get a list of all current board
+ members of legal entity X, so that I can Verify Stakeholders_
+ - _As an Employee, I need to get a list of all my colleagues in
+ my unit, so that I Know my Colleagues_
+ - _As a customer, I need to get a list of all products, so that
+ I can make a product selection_
+
+ And so forth.
+ That's all we ask in the early phases of a given use case.
+
+ ## Why Stories Matter
+
+ Stories provide a bridge between business needs and technical
+ implementation.
+ They ensure that:
+
+ - **Business language is preserved** — Requirements are captured
+ in terms the business understands
+ - **Focus stays on outcomes** — We understand the "why" behind
+ each requirement
+ - **Everyone is aligned** — Business, data, and technology
+ teams share a common understanding of what needs to be
+ delivered
+
=== "Data & Tech Audience"
- "User Stories" start out as plain English sentences that, as the name suggests, come from the user.
- In other words, "the Business" or "the Customer", the end user of a system or application, is
- responsible for explaining to the people who need to deliver that system what the system is supposed to do.
-
- Makes sense right? Unfortunately, it's usually not that simple.
- All kinds of other factors come into play that have nothing to do with specifying what the user
- _really_ wants such as design, architecture, existing systems, budgets, time, regulations, policies
- and technical capabilities.
-
- However, it is a good thing to at least capture the "real" wishes of the user without having to consider all of
- those other aspects.
- Where the challenge is to ask the user to step out of their normal day-to-day practices and comfort zone and to
- think ahead in a way that is not restricted by all the daily hurdles and practicalities.
- This method proposes to use "Structured Business User Stories" to achieve many things such as:
-
- * have a more strategic view on which functionality is ^^really^^ required
- * allow to see "the disconnect" or "the gap" between what's required and what is currently available,
- delivered and deliverable
- * avoid "tunnel thinking" where everyone, especially also "the business" itself, makes all kinds of
- assumptions that may or may not be true and could severely diminish creativity.
- * create a clear separation of concerns: the business specifies what they need but leaves it to the
- data and technology people to work out how they can deliver it.
- So no more "screen designs" (that comes later) or "schema's" that are used as
- "functional specification".
- We need to be able to go deeper, to the core questions about **"what do you ^^really^^ need?"**
- (and forget about the "How" for a minute).
- * have clear testable specifications of required functionality for the whole life-cycle of a given
- user story.
- As long as people need a given story to be implemented, it will continuously be tested "end-to-end",
- from inception all the way to production, not only before deployment into production but actually
- also in production itself.
- The EKG knows about "its Stories" and continuously tests them, it therefore knows about its own
- "functional health" and can detect whenever something changes (code, ontologies, ETL, new policies)
- whether it can still deliver all functionality
-
- Here's a diagram that illustrates how we can break up a user story in some interesting components that
- we can link to other data structures in the Knowledge Graph such as a taxonomy of all ["Personas"](persona.md)
-
-
- TODO
-
-
- Here's one example of a User Story, more examples will follow later:
-
-
- TODO
-
-
-
+ ## What Is a Story in the Use Case Tree Method?
+
+ "User Stories" start out as plain English sentences that, as the
+ name suggests, come from the user.
+ In other words, "the Business" or "the Customer" — the end user
+ of a system or application — is responsible for explaining to
+ the people who need to deliver that system what the system is
+ supposed to do.
+
+ Makes sense, right?
+ Unfortunately, it's usually not that simple.
+ All kinds of other factors come into play that have nothing to
+ do with specifying what the user _really_ wants, such as design,
+ architecture, existing systems, budgets, time, regulations,
+ policies, and technical capabilities.
+
+ ## The Challenge
+
+ However, it is a good thing to at least capture the "real"
+ wishes of the user without having to consider all of those other
+ aspects.
+ The challenge is to ask the user to step out of their normal
+ day-to-day practices and comfort zone and to think ahead in a
+ way that is not restricted by all the daily hurdles and
+ practicalities.
+
+ ## Structured Business User Stories
+
+ This method proposes to use "Structured Business User Stories"
+ to achieve many things:
+
+ ### Strategic Focus
+
+ Have a more strategic view on which functionality is **really**
+ required.
+ By focusing on business outcomes rather than implementation
+ details, we can identify what truly matters.
+
+ ### Gap Analysis
+
+ Allow seeing "the disconnect" or "the gap" between what's
+ required and what is currently available, delivered, and
+ deliverable.
+ This helps prioritize work and identify areas where new
+ capabilities are needed.
+
+ ### Avoid Tunnel Thinking
+
+ Avoid "tunnel thinking" where everyone, especially "the business"
+ itself, makes all kinds of assumptions that may or may not be true
+ and could severely diminish creativity.
+ Stories encourage thinking beyond current constraints.
+
+ ### Separation of Concerns
+
+ Create a clear separation of concerns: the business specifies what
+ they need but leaves it to the data and technology people to
+ work out how they can deliver it.
+ So no more "screen designs" (that comes later) or "schemas" that
+ are used as "functional specification".
+ We need to be able to go deeper, to the core questions about
+ **"what do you really need?"** (and forget about the "How" for a
+ minute).
+
+ ### Testable Specifications
+
+ Have clear testable specifications of required functionality for
+ the whole lifecycle of a given user story.
+ As long as people need a given story to be implemented, it will
+ continuously be tested "end-to-end," from inception all the way
+ to production, not only before deployment into production but
+ actually also in production itself.
+
+ ## Continuous Testing and Functional Health
+
+ The EKG knows about "its Stories" and continuously tests them.
+ It therefore knows about its own "functional health" and can
+ detect whenever something changes (code, ontologies, ETL, new
+ policies) whether it can still deliver all functionality.
+
+ This means that Stories are not just requirements documents —
+ they are **living, executable specifications** that the EKG
+ monitors and validates throughout their entire lifecycle.
+
+ ## Relationship to Workflows
+
+ Stories are executed as steps within [Workflows](workflow.md).
+ For each Story, we always know in which Workflows it participates
+ as a Step.
+
+ This bidirectional relationship enables:
+
+ - **Story reuse** — Stories can be reused across multiple
+ workflows, enabling composition and consistency
+ - **Workflow discovery** — Understanding which workflows use a
+ given story helps discover related business processes
+ - **Impact analysis** — Knowing what workflows are affected when
+ a story changes enables better change management
+ - **Process understanding** — Seeing how stories are composed
+ into workflows provides insight into business processes
+
+ Stories define the "what" (the capability), while Workflows
+ define the "how" (the sequence and order of execution).
+
+ ## Relationship to Other Concepts
+
+ Stories link to other data structures in the Knowledge Graph:
+
+ - **[Personas](persona.md)** — Each Story specifies which
+ Persona needs the capability
+ - **[Use Cases](use-case.md)** — Stories are organized within
+ Use Cases, defining the functional requirements
+ - **[Outcomes](outcome.md)** — The "why" part of a Story links
+ to business outcomes
+ - **[Concepts](concept.md)** — Stories reference domain concepts
+ that need to be understood and modeled
+ - **[Workflows](workflow.md)** — Stories are executed as steps
+ within workflows
+
+ This integration ensures that Stories are not isolated
+ requirements but part of a cohesive, semantic model of the
+ enterprise.
+
+=== "Ontology"
+
+ ## Ontology (minimal facts we can state today)
+
+ --8<-- "fragment/uctm-diagram-story.md"
+
+ We're not (yet) prescribing a full OWL ontology here.
+ But we can state a small set of **facts** that people can reliably use to build their own
+ ontology / schema / graph model around a Story.
+
+ ### Required facts about a Story
+
+ - **Opaque universally unique identifier**
+ - A Story must have an **opaque**, **universally unique** identifier.
+ - Prefer a random identifier such as **UUIDv4**.
+ - Represent it as a URI, for example:
+ `urn:uuid:550e8400-e29b-41d4-a716-446655440000`
+
+ - **Business-friendly name**
+ - A Story should have a concise, human-readable name.
+
+ - **Slug**
+ - A Story should have a kebab-cased slug that is unique at least within the organization.
+ - Example: `assess-risk-position`, `verify-stakeholders`
+
+ - **Business-focused definition**
+ - A Story must have a plain-language definition of what the user needs.
+
+ - **Structured statement (who / what / why)**
+ - A Story should capture:
+ - **Who**: a reference to a Persona (or persona-like Concept)
+ - **What**: the capability/action needed
+ - **Why**: a reference to an Outcome (the intended business value)
+
+ - **Owned by a Use Case**
+ - A Story is **part-of** a Use Case: the Use Case **owns** the Story.
+ - If the owning Use Case is deleted, its Stories are deleted as well.
+
+ - **Concept usage (relationship-object)**
+ - Model the relationship between a Story and a Concept as a **relationship-object**
+ (not a direct link), because it carries meaning about *how* the Concept is used.
+ - The relationship-object defines a usage type, for example:
+ - **Input Concept** — required/mandatory input parameter (or optional)
+ - **Output Concept** — definition of the output (often a shape/compound object)
+ - **Dependent Concept** — referenced in filters/constraints (e.g., SQL/SPARQL `WHERE`)
+
+ - **Workflow participation**
+ - A Story can participate as a **Step** in one or more WorkflowDefinitions.
+ - Model this via a relationship-object (e.g. a “WorkflowStep”) so you can capture step
+ order, conditions, and other execution semantics.
diff --git a/docs/concept/term.md b/docs/concept/term.md
new file mode 100644
index 00000000..73158717
--- /dev/null
+++ b/docs/concept/term.md
@@ -0,0 +1,159 @@
+---
+description: "A manifestation of a Concept: a business-facing or technical term (e.g., synonyms, abbreviations, variable names) that all mean the same thing in the Concept’s context. Learn how Terms work in the Use Case Tree Method."
+keywords:
+ - term
+ - business term
+ - technical term
+ - concept term
+ - EKG method
+ - enterprise knowledge graph
+schema_type: "Article"
+---
+
+# Term
+
+
+_A manifestation of a Concept: the words (business-facing and technical) used to refer to the same underlying meaning_
+
+
+=== "Business & Management Audience"
+
+ ## What Is a Term?
+
+ A **Term** is a word or phrase people use to refer to a [Concept](concept.md) in a given
+ context.
+ Concepts are about **meaning**; Terms are about **how that meaning shows up** in language.
+
+ A Concept can have multiple Terms (synonyms, abbreviations, variations), but they all refer
+ to the **same meaning** in the context of that Concept.
+
+ ## Business Terms vs Technical Terms
+
+ Terms come in two broad categories:
+
+ - **Business Terms** — user-facing terminology used in conversations, documentation, UI, and
+ policies (e.g., “Customer”, “Counterparty”, “Risk Position”)
+ - **Technical Terms** — manifestations in code and data (e.g., variable names, column names,
+ API parameters, query bindings)
+
+ Treat both as Terms, because both are used by people, and both need to be linked back to the
+ Concept so everyone stays aligned.
+
+=== "Data & Tech Audience"
+
+ ## Terms as Concept Manifestations
+
+ A Term is a **manifestation** of a Concept.
+ It can be:
+
+ - a preferred business phrase
+ - an abbreviation
+ - a synonym
+ - a technical symbol in code (e.g., `_customer`, `cust_id`, `?cust`, `/customers`)
+
+ Terms allow the Knowledge Graph to connect human language and technical artifacts back to a
+ consistent semantic core (the Concept).
+
+ ## Discovering Technical Terms in code and data
+
+ Technical Terms can often be **discovered automatically** by scanning the organization’s
+ repositories and data artifacts:
+ Python/Java code, SQL, configuration, CSV column headers, API specs, and more.
+
+ Each detected manifestation becomes a **Technical Term** that links to:
+
+ - the **Concept** it manifests, and optionally
+ - the **Business Term** it corresponds to in that context.
+
+ Example:
+ If you detect the CSV header `P`, you can link that Technical Term to the Concept and also to
+ the Business Term “Patient”.
+
+ Technical Terms also include **semantic/validation artifacts** introduced later in the Use
+ Case lifecycle (especially during the Build phase), such as:
+
+ - OWL classes/properties/axioms in an ontology, and
+ - SHACL shapes and constraints.
+
+ In those cases, you link the Concept (and optionally a Business Term) to the ontology/shapes
+ term via a **special mapping relationship** (e.g. “representsClass”, “representsProperty”,
+ “constrainedByShape”), pointing at the ontology IRI.
+
+ Example:
+ If the Concept “patient” corresponds to the OWL class `hospital:Patient` in a Hospital
+ ontology, create a Technical Term representing that ontology term and link it with something
+ like **representsClass → `hospital:Patient`**.
+
+ ## Preferred Term
+
+ Concepts don’t need a traditional `rdfs:label` / `skos:prefLabel` label.
+ Instead, a Concept can point to a **preferred Term** (a Term object) that represents the
+ preferred expression in that context.
+
+=== "Ontology"
+
+ ## Ontology (minimal facts we can state today)
+
+ --8<-- "fragment/uctm-diagram-term.md"
+
+ We're not (yet) prescribing a full OWL ontology here.
+ But we can state a small set of **facts** that people can reliably use to build their own
+ ontology / schema / graph model around a Term.
+
+ ### Required facts about a Term
+
+ - **Opaque universally unique identifier**
+ - A Term should have an **opaque**, **universally unique** identifier.
+ - Prefer a random identifier such as **UUIDv4**, represented as a URI:
+ `urn:uuid:550e8400-e29b-41d4-a716-446655440000`
+
+ - **One or more forms (lexical variants)**
+ - A Term must have **one or more textual forms** (the actual strings).
+ - Business Terms often need multiple forms for different UI / communication contexts, for
+ example:
+ - **Singular**: “Patient”
+ - **Plural**: “Patients”
+ - **Abbreviation**: “Pat.”
+ - **Short label**: “P”
+ - These are variations of the **same Term** (think “sub-manifestations” of the Term).
+ They should not be mixed with the forms of a different Term.
+
+ Example:
+ If “Patient” and “Client” are both used to mean the same thing in a given Use Case
+ context, model them as **two separate Business Term objects**, each with their own
+ lexical forms.
+ Both Terms link to the same Concept, and the Concept defines the shared meaning.
+
+ - **Term kind**
+ - A Term should indicate whether it is a **Business Term** or a **Technical Term**.
+
+ - **Owned by a Concept**
+ - Terms are **owned** by a Concept (part-of): when the Concept is deleted, its Term
+ objects are deleted as well.
+ - A Concept must have **one or more Terms**.
+ - All Terms for a Concept **mean the same thing** in that Concept’s context.
+
+ ### Optional but useful facts
+
+ - **Language**: natural language tag for business terms (e.g., `en`, `nl`)
+ - **System / artifact**: where a technical term appears (e.g., codebase, dataset, API)
+ - **Term subtype**: for technical terms (e.g., `VariableName`, `ColumnName`, `ApiFieldName`,
+ `QueryBinding`)
+ - **Provenance**: who introduced the term, when, and why
+
+ ### Optional facts for Technical Terms (recommended)
+
+ When a Term is discovered in code/data, capture **where it came from**:
+
+ - **Repository URL** (e.g., GitHub repo)
+ - **File path**
+ - **Line range** (or equivalent location for non-text artifacts)
+ - **Commit / tag / revision**
+ - **Language / format** (e.g., Python, Java, SQL, CSV)
+ - **Locator URL** (deep link to the exact source line / blob for traceability)
+
+ When a Term represents an ontology or validation artifact, capture:
+
+ - **Ontology / shape identifier** (IRI), e.g. `hospital:Patient`
+ - **Mapping kind** (e.g., representsClass / representsProperty / constrainedByShape)
+
diff --git a/docs/concept/use-case-tree.md b/docs/concept/use-case-tree.md
index 29b83d03..4f98a0b6 100644
--- a/docs/concept/use-case-tree.md
+++ b/docs/concept/use-case-tree.md
@@ -1,129 +1,235 @@
+---
+description: "The foundational structure that organizes business capabilities into reusable, governed components within the Enterprise Knowledge Graph. Learn how the Use Case Tree drives EKG development."
+keywords:
+ - use case tree
+ - UCT
+ - business capabilities
+ - EKG method
+ - enterprise knowledge graph
+ - strategic planning
+schema_type: "Article"
+---
+
# Use Case Tree (UCT)
-!!! warn
-
- Work in progress
-
-Some notes as input for this article (to still be written):
-
-- The Use Case Tree is a model at a higher level of abstraction than User Stories.
-- It is a differentiator in the EKG/Method
-- It enables consultative discussion that can identify options enterprises may otherwise not consider
-- There is a need for something above User Stories to help define scope and priority
-- The most critical and most important ”artifact” in the development of an Enterprise Knowledge Graph
- (EKG) is “the Use Case Tree” (UCT).
- - The Use Case Tree is the EKG’s equivalent of a long term data strategy and business capability plan.
- - The Use Case Tree is the EKG high level requirements overview, scoping and dependency model.
- In its initial stages, in the [Plan Phase](../process/plan/index.md), it gives a mile wide, inch deep view
- of business capabilities.
-- The Use Case Tree is a breakdown of strategic planned-for capabilities into smaller building blocks, all
- called ”use cases”. Strategic long term use cases such as
- ”[Enterprise Risk Management](https://catalog.ekgf.org/use-case/risk-management/)” or
- ”[Client 360](https://catalog.ekgf.org/use-case/client-360/)”
- are broken down into smaller use cases that can (and should) be done first.
-- Each ”use case” is a module, an EKG component so you will, a building block with which other use cases
- can be constructed.
-- Everything we ever do in a business, especially in the data and technology pillars of that enterprise,
- should be related to ”a use case” in the Use Case Tree.
-- The ”Use Case Tree” is a practice and is part of the Enterprise Knowledge Graph Method (EKG/Method).
-
-## The primary reasons for creating a Use Case Tree are:
-
-### 1. Know what the business wants.
-
-Know exactly what the business---i.e. the customer or product owner---really needs, short-, mid-
-and long-term.
-
-#### (a) Plan phase: Discover the business opportunities & business needs
-
-One of the tasks during the planning phase of any new initiative – or iteration – is to ”Discover”
-the business opportunities & needs:
-
-- In non-technical terms.
-- Without assuming anything about existing systems and ”how things are done today”.
-- Translate to ”pure” functional requirements – and ”nice to haves”.
-- Looking broad horizontally, thinking ahead. Mile wide, inch deep at this stage.
-- Let the business ”dream a little” about ”what could be” and ”what should be” so that future
- needs can be identified and communicated – without necessarily committing to them (yet).
-- Promote ”thinking outside the box”, encourage people to not make any assumptions about
- what is technically possible or not – so often these assumptions unknowingly keep the bar
- lower than it could be.
-
-#### (b) Build phase: Translate requirements into an easy to understand model i.e. the Use Case Tree
-
-- ”Contract with the business” i.e. the budget holder or product owner., every major change
- to the Use Case Tree will have to be signed off by the product owner.
-- Capture it as ”meta-data” that will be part of the EKG – all the way to production.
-- Capture it in such a way that ”everything that we ever do” is always directly or indirectly
- relatable to ”a use case” in ”the Use Case Tree”.
-- The business never loses sight on what happens with their budget and agreed deliverables.
- All reporting to the business occurs in the context of the agreed Use Case Tree, even after
- delivery.
-
-### Bridge the traditional gap between Business & Technology.
-
-- Engage with the business, the product owner and get continuous buy-in from the product
- owner during the life-cycle of the agreed use cases.
-- But not only with the product owner of the direct use case being developed but also show to
- the business what other future needs need to be considered. For instance, if one use case
- e.g. ”Legal Entities” needs ”workflows”, would it make sense to invest a bit more effort to then
- create a reusable workflow component that can also be used for many other use cases such
- as ”Shareholding disclosure”?
-- Yes, the customer is always right but the Use Case Tree shows to the customer that there are
- many other customers (or future customers, in and outside the organization even) and why it
- makes sense to prioritize reuse and how that not only could deliver more quality but also create
- more buy-in from peer stakeholders across the firm or even across the industry.
-– In other words, do not select one product owner to be the single stakeholder but also get
- other stakeholders of neighboring or higher level use cases in the room, their requirements
- may influence the reuse agenda and therefore the roadmap. It may sound paradoxal but
- investing in reuse will not slow things down but speed things up.
-
-### Managed Expectations
-
-The Use Case Tree is the best form of ”expectation management”, creating an agreed and
-realistic strategic roadmap.
-
-### Modularity Managed
-
-The Use Case Tree is a foundational mechanism to create an ecosystem of reusable components
-for the EKG.
-
-### Avoids ”boiling the ocean”
-
-Semantic Technology based projects often spend a lot of time "boiling the ocean", modeling
-everything in a given domain. The Use Case Tree and its individual use cases define an agreed
-scope at the detail level (without becoming technical).
-
-- Provides focus for the Center of Excellence (CoE), ”cranking out” use cases one by one
-- Ontology development will be focussed on delivering on the requirements (user stories and
- concepts) of the agreed use cases rather than ending up in philosophical exercise.
-
-### Map of all Knowledge
-
-The Use Case Tree provides a ”map” of all knowledge, data and functionality (whether implemented
-as running EKG use cases or not) of the enterprise.
-Which is not only useful for users of the EKG but also a necessity since all of these use cases are
-served by one platform – albeit distributed and federated etc – there will be many stakeholders with
-different agendas that would not care – nor have to care – about the wishes of the stakeholders in
-other use cases. However, updates to one use case could potentially also affect other use cases.
-
-That’s why:
-
-1. all changes & updates have to be done gradually, no ”big bang” releases and
-2. all inter-dependencies need to be really clear and tested in-full automatically and continuously.
-
-So, for instance, when some sub-use case in a high-level use case is also used in another high-level
-use case then a change that serves the needs of one could potentially also affect the other and its
-users. That’s why we need the Use Case Tree, to allow us to avoid any disruption across the board.
-
-### Foundational structure for quality
-
-The Use Case Tree is a foundational structure for quality since it enforces, requires and
-enables 100% test coverage based on real business scenarios and requirements.
-
-- A use case has a life-cycle that starts with a name and a description and ends1 with a fully
- detailed model of all related concepts, personas, business outcomes, datasets, ontologies, user
- stories and dependencies. That model is all captured in the EKG itself which allows the EKG
- to not only fully and thoroughly test things during development time (build phase) but also
- in production (run phase). Which provides the level of quality that an EKG needs to have to
- become truly able to support enterprise level strategic use cases.
+
+_The foundational structure that organizes business capabilities into
+reusable, governed components within the Enterprise Knowledge Graph_
+
+
+## What Is the Use Case Tree?
+
+The **Use Case Tree (UCT)** is the most critical artifact in the
+development of an Enterprise Knowledge Graph (EKG).
+It is the EKG's equivalent of a long-term data strategy and business
+capability plan — a high-level requirements overview, scoping and
+dependency model that organizes everything the enterprise does.
+
+At its core, the Use Case Tree breaks down strategic business
+capabilities into smaller, reusable building blocks called
+**use cases**.
+Strategic use cases such as
+"[Enterprise Risk Management](https://catalog.ekgf.org/use-case/risk-management/)"
+or "[Client 360](https://catalog.ekgf.org/use-case/client-360/)" are
+decomposed into smaller use cases that can be implemented
+incrementally.
+
+Each use case in the tree acts as a **semantic package** — a module,
+component, and building block that can be discovered, versioned, and
+reused across the enterprise.
+Everything done in a business, especially in data and technology,
+should be traceable to a use case in the Use Case Tree.
+
+!!! tip "Higher-level abstraction"
+
+ The Use Case Tree operates at a higher level of abstraction than
+ User Stories.
+ It enables consultative discussions that identify options
+ enterprises might otherwise overlook, and provides the structure
+ needed to define scope and priority above the level of individual
+ stories.
+
+## Why the Use Case Tree Matters
+
+The Use Case Tree serves as the organizing principle for the entire
+Use Case Tree Method.
+It bridges the gap between business vision and technical execution,
+ensuring that every capability is designed for reuse and governed
+throughout its lifecycle.
+
+### Know What the Business Wants
+
+The Use Case Tree captures exactly what the business — customers,
+product owners, and stakeholders — really needs, short-, mid-, and
+long-term.
+
+#### During Planning: Discover Opportunities
+
+During the [Plan Phase](../process/plan/index.md), the Use Case Tree
+helps teams discover business opportunities and needs:
+
+- **In non-technical terms** — accessible to all stakeholders
+- **Without assumptions** about existing systems or "how things are
+ done today"
+- **As pure functional requirements** — distinguishing needs from
+ "nice to haves"
+- **With broad, forward-looking perspective** — mile wide, inch deep
+ at this stage
+- **Encouraging innovation** — letting the business "dream" about
+ "what could be" without premature technical constraints
+
+The goal is to think outside the box and avoid assumptions about
+technical limitations that might unnecessarily constrain
+possibilities.
+
+#### During Building: Translate to Executable Model
+
+In the [Build Phase](../process/build/index.md), the Use Case Tree
+becomes the contract with the business:
+
+- **Governed changes** — every major change requires product owner
+ sign-off
+- **Metadata in the EKG** — captured as part of the EKG itself,
+ persisting all the way to production
+- **Complete traceability** — everything done is directly or
+ indirectly relatable to a use case in the tree
+- **Ongoing visibility** — the business never loses sight of budget
+ and deliverables, with all reporting occurring in the context of
+ the agreed Use Case Tree
+
+### Bridge Business and Technology
+
+The Use Case Tree creates a shared language between business and
+technology teams.
+It enables continuous engagement with product owners and stakeholders
+throughout the lifecycle of use cases.
+
+!!! tip "Think beyond the immediate use case"
+
+ When developing a use case like "Legal Entities" that needs
+ workflows, the Use Case Tree helps identify opportunities for
+ broader reuse.
+ Should you invest more effort to create a reusable workflow
+ component that can also serve "Shareholding Disclosure" and other
+ use cases?
+
+ The tree shows stakeholders that there are many customers — current
+ and future, inside and outside the organization — and demonstrates
+ why prioritizing reuse delivers both quality and broader buy-in
+ across the firm or industry.
+
+By engaging multiple stakeholders — not just the direct product
+owner, but also stakeholders of neighboring or higher-level use cases
+— teams can identify reuse opportunities that accelerate delivery
+rather than slow it down.
+
+### Manage Expectations
+
+The Use Case Tree is the foundation of expectation management,
+creating an agreed and realistic strategic roadmap.
+It provides clarity on:
+
+- What will be delivered and when
+- How capabilities relate to business outcomes
+- Dependencies between use cases
+- Priorities and sequencing
+
+### Enable Modularity and Reuse
+
+The Use Case Tree is the foundational mechanism for creating an
+ecosystem of reusable components for the EKG.
+Each use case can be:
+
+- **Designed** as a reusable building block
+- **Versioned** and governed independently
+- **Composed** with other use cases to create larger capabilities
+- **Discovered** by teams across the enterprise
+
+This aligns directly with the objectives of
+[**Enable Reuse**](../objective/enable-reuse.md) and
+[**Composable Business**](../objective/composable-business.md).
+
+### Avoid "Boiling the Ocean"
+
+Semantic technology projects often spend excessive time modeling
+everything in a domain — "boiling the ocean."
+The Use Case Tree and its individual use cases define an agreed
+scope at the appropriate level of detail (without becoming overly
+technical).
+
+- **Provides focus** for the Center of Excellence (CoE), enabling
+ teams to deliver use cases incrementally
+- **Directs ontology development** toward delivering on the
+ requirements of agreed use cases, rather than philosophical
+ exercises
+
+### Map All Knowledge
+
+The Use Case Tree provides a comprehensive map of all knowledge,
+data, and functionality — whether implemented as running EKG use
+cases or planned for the future — across the enterprise.
+
+This map is essential because:
+
+- All use cases are served by one platform (albeit distributed and
+ federated)
+- Many stakeholders have different agendas and priorities
+- Updates to one use case can affect others
+
+That's why the Use Case Tree enforces:
+
+1. **Gradual, incremental changes** — no "big bang" releases
+2. **Clear inter-dependencies** — all dependencies are explicit and
+ tested automatically and continuously
+
+For example, when a sub-use case in one high-level use case is also
+used in another, changes serving one stakeholder's needs could affect
+others.
+The Use Case Tree makes these relationships visible, enabling teams to
+avoid disruption across the board.
+
+### Foundational Structure for Quality
+
+The Use Case Tree provides the foundational structure for quality by
+enforcing, requiring, and enabling 100% test coverage based on real
+business scenarios and requirements.
+
+A use case has a lifecycle that starts with a name and description and
+evolves into a fully detailed model including:
+
+- Related concepts and personas
+- Business outcomes and success criteria
+- Datasets and ontologies
+- User stories and workflows
+- Dependencies and relationships
+
+This model is captured entirely within the EKG itself, enabling:
+
+- **Comprehensive testing during development** (Build phase)
+- **Continuous validation in production** (Run phase)
+- **Quality assurance** at the level required for enterprise-scale
+ strategic use cases
+
+## Relationship to Other Concepts
+
+The Use Case Tree is closely related to several other concepts in the
+EKGF Method:
+
+- **[Use Case](use-case.md)** — Individual nodes in the tree
+- **[Enable Reuse](../objective/enable-reuse.md)** — The Use Case
+ Tree is the primary mechanism for enabling reuse
+- **[Composable Business](../objective/composable-business.md)** —
+ The tree organizes capabilities for composition
+- **[Persona](persona.md)**, **[Story](story.md)**,
+ **[Workflow](workflow.md)**, **[Data Product](data-product.md)**,
+ **[Ontology](ontology.md)** — All registered within use cases in
+ the tree
+
+## Summary
+
+The Use Case Tree is not just a planning tool — it is the living
+structure that organizes, governs, and enables reuse of every
+business capability in the Enterprise Knowledge Graph.
+It bridges business and technology, manages expectations, enables
+modularity, prevents scope creep, maps enterprise knowledge, and
+provides the foundation for quality at scale.
diff --git a/docs/concept/use-case.md b/docs/concept/use-case.md
index b7f1c52f..7066a44d 100644
--- a/docs/concept/use-case.md
+++ b/docs/concept/use-case.md
@@ -1,107 +1,400 @@
+---
+description: "An executable model of business requirements that delivers specific business outcomes within the Use Case Tree. Learn how use cases structure business capabilities in the Use Case Tree Method."
+keywords:
+ - use case
+ - business requirements
+ - EKG method
+ - enterprise knowledge graph
+ - use case tree
+schema_type: "Article"
+---
+
# Use Case
+
+_An executable model of business requirements that delivers specific
+business outcomes within the Use Case Tree_
+
=== "Business & Management Audience"
- A Use Case specifies a distinct set of business requirements --- ideally
- but not necessarily captured as an "executable model" --- resulting in
- a specific business outcome.
-
- It starts with ideas for use cases that could come from any person in
- the organization at any point in time.
- We want to capture all these ideas (and as much of the knowledge behind
- those ideas) and create one data structure for it that
- we call "the [Use Case Tree](use-case-tree.md)" because it looks like an inverted tree: it's
- something that starts on a whiteboard, showing a break-down of a
- component of the business into smaller components.
-
- Anyone should be able to contribute ideas that may or may not
- end up as fully implemented use cases to end up in the organization's
+ ## What Is a Use Case?
+
+ A **Use Case** specifies a distinct set of business requirements —
+ ideally, but not necessarily, captured as an "executable model" —
+ resulting in a specific business outcome.
+
+ Use cases start as ideas that can come from anyone in the
+ organization at any time.
+ These ideas are captured in the
+ [**Use Case Tree**](use-case-tree.md) — a data structure that
+ organizes business capabilities into a hierarchical structure,
+ starting on a whiteboard and showing how components of the business
+ break down into smaller components.
+
+ ## Open Contribution Model
+
+ Anyone should be able to contribute ideas that may or may not end
+ up as fully implemented use cases in the organization's
[Use Case Tree](use-case-tree.md), whether they are viable or not.
- If an idea for a given use case is rejected then show the rationale
- for that to everyone so that everyone can learn, and we're not wasting
- anyones time on that idea again.
- Let people contribute.
- All knowledge workers, all specialist users, data architects,
- technical architects, ontologists, end users, business executives,
- literally anyone should be allowed to understand:
-
- * What's our
+ If an idea for a use case is rejected, the rationale should be
+ shared with everyone so that everyone can learn and avoid wasting
+ time on that idea again.
+
+ !!! important "Let people contribute"
+
+ A Use Case is a **shared, living artifact** across the full end-to-end lifecycle
+ (Plan → Build → Run → evolve).
+ Everyone involved — knowledge workers, specialist users, data architects,
+ technical architects, ontologists, end users, business executives — literally anyone —
+ should be able to **read it**, **talk about the same Use Case (the same version)**,
+ and **contribute what they know** as the work progresses.
+
+ Everything you do in and around a Use Case should be discoverable back in the
+ **Knowledge Graph**, and be directly or indirectly related to that Use Case.
+
+ ### Strategic Context
+
+ - **Business identity and strategy**: What is our
[business identity](https://maturity.ekgf.org/pillar/business/background-and-intro/#business-identity)?
Our [mission and strategy](https://maturity.ekgf.org/pillar/business/capability-area/strategy-actuation/)?
- What do we all this for (besides being profitable), what are the long term
- objectives that we are going to achieve?
- * How does that map to our current and future data and technology landscape?
- * (without becoming too technical or detailed, we want everyone to be able to chip in)
- * [Assess](../process/plan/assess.md) all our organization's capabalities,
- as specified in the
- [Maturity Model for the Enterprise Knowledge Graph (EKG/Maturity)](https://maturity.ekgf.org)
- related to our own EKG and how they match with our ambitions to implement our
- strategic use cases?
- * How does our "technical debt" fit in? (identify the functionality of our
- technical debt as use cases in the tree as well)
- * How are we going to "rationalize" our current siloed landscape (and technical debt)?
- * What are the short and long term priorities?
- * What are the milestones and the roadmap? (see ["Chart"](../process/plan/chart.md))
- * Which ideas (for use cases) have been proposed, considered approved or rejected and why?
+ What do we do all this for (besides being profitable)? What are
+ the long-term objectives we are going to achieve?
+
+ - **Technology landscape**: How does that map to our current and
+ future data and technology landscape? (Without becoming too
+ technical or detailed — we want everyone to be able to
+ contribute.)
+
+ - **Capability assessment**: How do we
+ [Assess](../process/plan/assess.md) all our organization's
+ capabilities, as specified in the
+ [Maturity Model for the Enterprise Knowledge Graph (EKG/Maturity)](https://maturity.ekgf.org),
+ related to our own EKG and how they match with our ambitions to
+ implement our strategic use cases?
+
+ - **Technical debt**: How does our "technical debt" fit in?
+ (Identify the functionality of our technical debt as use cases
+ in the tree as well.)
+ How are we going to "rationalize" our current siloed landscape
+ (and technical debt)?
+
+ - **Priorities and roadmap**: What are the short- and long-term
+ priorities? What are the milestones and the roadmap? (See
+ ["Chart"](../process/plan/chart.md).)
+
+ - **Transparency**: Which ideas (for use cases) have been
+ proposed, considered, approved, or rejected, and why?
=== "Data & Tech Audience"
- The term "use case" means something specific to a technical audience who
- usually assume that the term use case means what the Object Management Group (OMG)
- defines what it is in their Unified Modeling Language (UML) and
- its ["use case diagrams"](https://en.wikipedia.org/wiki/Use_case_diagram).
+
+ ## What Is a Use Case in the Use Case Tree Method?
+
+ A **Use Case** in the Use Case Tree Method specifies a distinct set of
+ business requirements — ideally captured as an "executable model"
+ — resulting in a specific business outcome.
+ Each use case is a node in the
+ [**Use Case Tree**](use-case-tree.md), acting as a semantic
+ package that can be discovered, versioned, and reused across the
+ enterprise.
+
+ ## Relationship to UML Use Cases
+
+ The term "use case" has a specific meaning for technical audiences
+ who typically assume it means what the Object Management Group (OMG)
+ defines in their Unified Modeling Language (UML) and its
+ ["use case diagrams"](https://en.wikipedia.org/wiki/Use_case_diagram).
+
+ Although there are many similarities and overlap — which is why we
+ are repurposing the term — it is not exactly the same in our Use
+ Case Tree Method:
+
+ ### Key Differences
+
+ - **Broader abstraction**: Use cases in the Use Case Tree Method are often
+ used as a much broader and more abstract container concept
+ compared to a UML Use Case.
+ They can be organized in a "tree structure" where, at the
+ highest levels, a use case can represent a capability domain or
+ a "strategic use case" — basically anything that fits well with
+ the business.
+
+ - **Reusable components**: At the lowest levels in this tree, we
+ end up with use cases that are much more like turn-key
+ components for the EKG — 100% reusable, delivering
+ "no-code"-functionality[^2].
+
+ [^2]: [No-code](https://en.wikipedia.org/wiki/No-code_development_platform) or
+ [Low-code](https://en.wikipedia.org/wiki/Low-code_development_platform)
+ development allows non-programmers to create applications without
+ hard-wiring business logic with a programming language
+
+ - **Executable models**: Unlike UML use cases, which are primarily
+ descriptive, EKG use cases can be captured as executable models
+ that run directly in the Enterprise Knowledge Graph platform.
+
+ - **Semantic packaging**: Each use case acts as a semantic package
+ containing ontologies, stories, data products, workflows, and
+ other reusable components — similar to how software packages
+ contain code, dependencies, and metadata.
+
+ ## Technical Implementation
+
+ From a technical perspective, a Use Case in the Use Case Tree Method:
+
+ - **Organizes related components**: Groups together personas,
+ concepts, stories, workflows, datasets, and ontologies that
+ belong to the same business capability
+
+ - **Enables reuse**: Provides a mechanism for discovering and
+ reusing business logic, data models, and workflows across
+ different contexts
+
+ - **Supports versioning**: Can be versioned and evolved over time
+ while maintaining backward compatibility
+
+ - **Facilitates testing**: Provides the structure for defining test
+ scenarios and ensuring 100% test coverage based on real business
+ requirements
+
+ - **Enables composition**: Can be composed with other use cases to
+ create larger business capabilities, supporting the goal of
+ [Composable Business](../objective/composable-business.md)
+
+=== "Key Components"
+
+ ## Overview
+
+ A Use Case in the Use Case Tree Method is composed of multiple components
+ that evolve throughout its lifecycle.
+ These components work together to create a complete, executable
+ model of business requirements.
+
+ ## Essential Elements
+
+ Every Use Case starts with these fundamental components, defined
+ during the [Plan Phase](../process/plan/index.md):
+
+ - **Name and description** — Clear identification and purpose.
+ This provides the foundation for all other components and
+ enables discovery within the Use Case Tree.
+
+ - **Business outcomes** — The desired or expected business
+ outcome(s) and how they can be measured.
+ These define success criteria and provide the "why" behind
+ the use case.
+ See [Outcome](outcome.md) for more details.
+
+ - **Personas** — The [personas](persona.md) of all the people and
+ systems involved in the domain or scope represented by the Use
+ Case.
+ Personas define who (or what) interacts with the use case and
+ their needs.
+
+ - **Concepts and terms** — The concepts and their terms as used
+ in the context of the Use Case.
+ These form the vocabulary of the domain and link to the
+ semantic models (ontologies) that will be developed.
+ See [Concept](concept.md) for more details.
+
+ !!! tip "Start simple, evolve iteratively"
+
+ These essential elements can be defined at a high level
+ initially — "mile wide, inch deep" — and refined as the use
+ case progresses through its lifecycle.
+
+ ## Additional Elements (Later in Lifecycle)
+
+ As the Use Case moves into the [Build Phase](../process/build/index.md),
+ additional components are added:
+
+ - **Stories** — The functional requirements and business logic
+ that implement the use case.
+ Stories define what the use case does and can be implemented
+ as executable functions or APIs.
+ See [Story](story.md) for more details.
+
+ - **Datasets and ontologies** — The data structures and semantic
+ models that support the use case.
+ Datasets provide the data, while ontologies define the meaning
+ and relationships.
+ See [Data Product](data-product.md) and
+ [Ontology](ontology.md) for more details.
+
+ - **Workflows** — The process flows and orchestration that
+ coordinate multiple stories and data flows.
+ Workflows define how different components work together to
+ deliver the business outcome.
+ See [Workflow](workflow.md) for more details.
+
+ ## Specialist Contributions
+
+ Throughout the lifecycle, specialists from various disciplines
+ in the organization contribute additional details:
+
+ - **Business analysts** — Detailed business rationale, tied to
+ the business outcomes, and requirements refinement
- Although there are many similarities and overlap --- which is why we are repurposing
- the term --- it is not exactly the same, in our Use Case Tree Method:
+ - **Project managers** — Milestones, versions, projects,
+ timelines, roadmaps, and budgets
- - use cases often are used a much broader and more abstract container concept ---
- compared to a UML Use Case --- that can be put in a "tree structure" where at the
- highest levels of these trees a use case can represent a capability domain or
- a "strategic use case" --- or basically anything that fits well with the business.
- - at the lowest levels in this tree we would end up with use cases that are much more
- like turn-key components for the EKG, 100% reusable delivering "no code"-functionality[^2].
+ - **Development teams** — Issues, tickets, and implementation
+ details
-=== "Key components"
+ - **Operations teams** — Environment topologies, deployments,
+ and configurations
- For every Use Case we specify:
+ - **Architects** — Detailed information about dependencies,
+ integrations, and technical relationships
- - A name and a description
- - The desired or expected business outcome(s) and how they can be measured
- - The ["personas"](persona.md) of all the people and systems that are involved
- in the domain or scope represented by the Use Case
- - The concepts and their terms as they're used in the context of the Use Case
+ ## Component Relationships
- At a later stage in the life-cycle of the Use Case we add:
+ These components are not independent — they form an integrated
+ whole:
- - The stories, see [Story](story.md)
- - The datasets and their ontologies
- - The workflows
+ - **Personas** interact with **Stories** to deliver **Business
+ Outcomes**
+ - **Stories** consume and produce **Data Products** using
+ **Ontologies** for semantic meaning
+ - **Workflows** orchestrate **Stories** to create end-to-end
+ business processes
+ - **Concepts** link to **Ontologies** that provide the semantic
+ foundation
+ - All components are versioned, tested, and governed together as
+ part of the Use Case
- Specialists of various disciplines in the organization can add their details
- such as:
+ This integrated approach ensures that every component is
+ traceable, reusable, and aligned with the business outcomes the
+ use case is designed to deliver.
- - detailed business rationale, tied to the before-mentioned business outcomes
- - milestones, versions, projects, timelines, roadmaps, budgets
- - issues, tickets
- - environment topologies, deployments and configurations
- - detailed information about the various types of dependencies
+=== "Process"
-=== "Life cycle"
+
+ ## Continuous Improvement
- Each individual Use Case itself goes through a life-cycle of continuous improvement like:[^1]
+ Each individual Use Case goes through a lifecycle of continuous
+ improvement:[^1]
+ This lifecycle spans the entire Use Case Tree Method process, from initial
+ idea through planning, building, running, and ongoing optimization.
- 
+ 
-=== "Plan/Build/Run"
+ ## Lifecycle Stages
- The EKG/Method defines a process that consists of three phases where each phase has
- well-defined "steps":
- [Plan](../process/plan/index.md),
- [Build](../process/build/index.md) and
+ The Use Case lifecycle aligns with the three main phases of the
+ Use Case Tree Method:
+
+ ### Plan Phase
+
+ During the [Plan Phase](../process/plan/index.md), the use case
+ starts as an idea and evolves into a well-defined requirement:
+
+ - **Ideation** — Initial concept or business need identified
+ - **Discovery** — Business opportunities and needs explored
+ - **Definition** — Essential elements defined (name, description,
+ outcomes, personas, concepts)
+ - **Scoping** — Boundaries and dependencies identified
+ - **Prioritization** — Position in the Use Case Tree established
+
+ At this stage, the use case is "mile wide, inch deep" — broad in
+ scope but not yet detailed in implementation.
+
+ ### Build Phase
+
+ During the [Build Phase](../process/build/index.md), the use case
+ becomes executable:
+
+ - **Design** — Stories, workflows, and data models designed
+ - **Development** — Components implemented (ontologies, data
+ products, stories)
+ - **Testing** — Test scenarios defined and executed, ensuring 100%
+ test coverage
+ - **Integration** — Components integrated and dependencies resolved
+ - **Verification** — Business outcomes validated against success
+ criteria
+
+ The use case transitions from a requirement to an executable,
+ testable capability.
+
+ ### Run Phase
+
+ During the [Run Phase](../process/run/index.md), the use case
+ operates in production:
+
+ - **Deployment** — Use case deployed to production environment
+ - **Operation** — Monitoring, maintenance, and support
+ - **Measurement** — Business outcomes measured and tracked
+ - **Optimization** — Continuous improvement based on performance
+ data and feedback
+ - **Evolution** — Updates and enhancements based on changing
+ business needs
+
+ The use case becomes a living, evolving capability that delivers
+ ongoing business value.
+
+ ## Iterative Refinement
+
+ The lifecycle is not linear — use cases continuously evolve:
+
+ - **Feedback loops** — Learnings from Run phase inform future Plan
+ and Build activities
+ - **Incremental delivery** — Use cases can be delivered in
+ increments, with each increment building on the previous
+ - **Versioning** — Changes are versioned to maintain stability
+ while enabling evolution
+ - **Reuse** — Successful use cases become reusable components for
+ future use cases
+
+ !!! tip "Lifecycle as a learning cycle"
+
+ The Use Case lifecycle is fundamentally a learning cycle.
+ Each phase provides feedback that improves the next iteration,
+ ensuring that the use case continuously aligns with business
+ needs and delivers increasing value over time.
+
+ ## Relationship to Use Case Tree
+
+ The lifecycle of individual use cases is managed within the context
+ of the [Use Case Tree](use-case-tree.md):
+
+ - **Tree structure** — The tree shows relationships and
+ dependencies between use cases
+ - **Governance** — Changes to use cases are governed through the
+ tree structure
+ - **Reuse** — The tree enables discovery and reuse of use cases
+ across the enterprise
+ - **Evolution** — The tree evolves as use cases progress through
+ their lifecycles
+
+ This ensures that individual use case lifecycles are coordinated
+ and aligned with the broader enterprise strategy.
+
+
+ ## Use Cases Across the Use Case Tree Method Process
+
+ The Use Case Tree Method defines a process consisting of three phases, each
+ with well-defined steps:
+ [Plan](../process/plan/index.md),
+ [Build](../process/build/index.md), and
[Run](../process/run/index.md).
- The common artifact across each of these phases---and most of their steps---is the Use Case Tree
- where certain information is relevant to that phase for each of its Use Cases:
+
+ The **Use Case Tree** is the common artifact across each of these
+ phases — and most of their steps.
+ As a use case progresses through these phases, different types of
+ information become relevant and are captured within the use case.
+
+ !!! tip "Progressive elaboration"
+
+ Use cases start simple in the Plan phase and progressively
+ gain detail as they move through Build and Run.
+ This approach ensures that investment is made incrementally,
+ with each phase building on the previous one.
+
+ ## Information by Phase
+
+ The following shows what information is captured for each use case
+ during each phase:
@@ -109,17 +402,18 @@
-----
- 1. Name + Business Description
- 2. Desired Business Outcomes
+ 1. **Name + Business Description**
+ 2. **Desired Business Outcomes**
- Definition of Success
- 3. [Personas](../concept/persona.md), [Concepts & Terms](../concept/concept.md)
+ 3. **[Personas](../concept/persona.md), [Concepts & Terms](../concept/concept.md)**
- Add examples i.e. input for test scenarios
- 4. [Stories](../concept/story.md) & [Workflows](../concept/workflow.md)
- - High level but agreed, metrics based estimates
- 5. Tree Structure
- - Break-down into---existing or non-existing---sub-use cases
- (some of which are reusable and some of which are specific to the parent use case)
- - Priority is to look up in the tree, not down, and define the longer term “strategic use cases” as well
+ 4. **[Stories](../concept/story.md) & [Workflows](../concept/workflow.md)**
+ - High level but agreed, metrics-based estimates
+ 5. **Tree Structure**
+ - Break-down into existing or non-existing sub-use cases
+ (some reusable, some specific to the parent use case)
+ - Priority is to look up in the tree, not down, and define
+ the longer-term "strategic use cases" as well
[:octicons-arrow-right-24: Learn more about the _Discover Step_](../process/plan/discover.md)
@@ -127,23 +421,26 @@
-----
- 6. Datasets
- - identify existing datasets or develop new
+ 6. **Datasets**
+ - Identify existing datasets or develop new
[_Self-describing datasets_ (SDDs)](https://principles.ekgf.org/vocab/sdd)
- 7. Ontologies
- - map the given [Concepts](../concept/concept.md) to the right Ontologies
- 8. Test scenarios
- - define test-datasets and test-scenarios for each [Story](../concept/story.md)
- - provision continuous integration pipelines for continuous automated testing
- - ensure 100% test coverage across all stories
- 9. Story-implementation details
- - all optional -- e.g. SPARQL, SHACL, SQL, workflow, audit,
- history, provenance, entitlements, caching policies, etc
- 10. Metrics
- - function point or story point-like metrics
- - lead / cycle time metrics
- - predict cost & delivery
- - based on metrics of previous use cases
+ 7. **Ontologies**
+ - Map the given [Concepts](../concept/concept.md) to the
+ right Ontologies
+ 8. **Test Scenarios**
+ - Define test-datasets and test-scenarios for each
+ [Story](../concept/story.md)
+ - Provision continuous integration pipelines for continuous
+ automated testing
+ - Ensure 100% test coverage across all stories
+ 9. **Story Implementation Details**
+ - All optional — e.g. SPARQL, SHACL, SQL, workflow, audit,
+ history, provenance, entitlements, caching policies, etc.
+ 10. **Metrics**
+ - Function point or story point-like metrics
+ - Lead / cycle time metrics
+ - Predict cost & delivery
+ - Based on metrics of previous use cases
[:octicons-arrow-right-24: Learn more](../process/build/index.md)
@@ -151,27 +448,289 @@
-----
- Additional detail added after deployment.
+ 11. **Operational Metrics**
+ - Performance data and usage statistics
+ - Business outcome measurements
+ - Quality metrics and error rates
+ 12. **Production Configuration**
+ - Environment details and deployment info
+ - Monitoring and alerting setup
+ - Backup and recovery procedures
+ 13. **Optimization Opportunities**
+ - Performance improvements identified
+ - User feedback and enhancement requests
+ - Cost optimization insights
+ 14. **Evolution Planning**
+ - Updates and enhancements planned
+ - Version roadmap
+ - Integration with new use cases
[:octicons-arrow-right-24: Learn more](../process/run/index.md)
-
+ ## Phase Transitions
+
+ Use cases transition between phases based on readiness criteria:
+
+ - **Plan → Build**: When business outcomes are defined, personas
+ identified, and high-level stories agreed upon
+ - **Build → Run**: When components are implemented, tested (100%
+ coverage), and verified against business outcomes
+ - **Run → Plan/Build**: When optimization or evolution requires
+ new planning or building activities
+
+ These transitions are not always linear — use cases may iterate
+ within phases or return to earlier phases based on feedback and
+ changing requirements.
+
+ ## Continuous Evolution
+
+ Even after deployment, use cases continue to evolve:
+
+ - **Measurement** drives understanding of what works and what
+ doesn't
+ - **Optimization** improves performance and reduces costs
+ - **Evolution** adds new capabilities based on business needs
+ - **Reuse** enables other use cases to leverage successful
+ components
+ This continuous evolution ensures that use cases remain aligned
+ with business needs and continue to deliver value over time.
+
+ [^1]: The lifecycle diagram shown is a simplification
=== "Similar Concepts"
- * Packaged Business Capabilities
- * [WalkMe - Packaged Business Capabilities (PBCs)](https://www.walkme.com/glossary/packaged-business-capabilities/)
- * [ElasticPath - What Are Packaged Business Capabilities (PBCs)?](https://www.elasticpath.com/blog/what-are-packaged-business-capablities)
+ ## Related Approaches
+
+ The concept of Use Cases in the Use Case Tree Method shares similarities with
+ several other approaches in enterprise architecture and software
+ development.
+ Understanding these relationships can help contextualize how Use
+ Cases fit into broader industry practices.
+
+ ### Packaged Business Capabilities (PBCs)
+
+ **Packaged Business Capabilities (PBCs)** are a concept from
+ composable commerce and enterprise architecture that emphasizes
+ modular, reusable business components.
+
+ **Similarities with EKG Use Cases:**
+
+ - **Modular design** — Both PBCs and Use Cases represent
+ self-contained business capabilities
+ - **Reusability** — Both are designed to be reused across different
+ contexts
+ - **Composability** — Both can be composed to create larger
+ capabilities
+ - **Business focus** — Both emphasize business value over technical
+ implementation
+
+ **Key Differences:**
+
+ - **Scope** — PBCs are typically focused on commerce and business
+ applications, while Use Cases in the Use Case Tree Method span all
+ enterprise capabilities
+ - **Semantic foundation** — EKG Use Cases are built on semantic
+ models (ontologies) that enable deeper integration and
+ interoperability
+ - **Executability** — EKG Use Cases can be captured as executable
+ models that run directly in the Enterprise Knowledge Graph
+ - **Tree structure** — Use Cases are organized in a hierarchical
+ Use Case Tree that provides governance and dependency management
+
+ **Learn More:**
+
+ - [WalkMe - Packaged Business Capabilities (PBCs)](https://www.walkme.com/glossary/packaged-business-capabilities/)
+ - [ElasticPath - What Are Packaged Business Capabilities (PBCs)?](https://www.elasticpath.com/blog/what-are-packaged-business-capablities)
+
+ ### UML Use Cases
+
+ As discussed in the [Data & Tech Audience](#data-tech-audience)
+ tab, Use Cases in the Use Case Tree Method share terminology with UML Use
+ Cases but operate at a different level of abstraction.
-[^1]: the life-cycle diagram shown is obviously a simplification
-[^2]: [No-code](https://en.wikipedia.org/wiki/No-code_development_platform) or
- [Low-code](https://en.wikipedia.org/wiki/Low-code_development_platform) development
- allows non-programmers to create applications without
- hard-wiring business logic with a programming language
+ **Key Distinctions:**
+ - **Abstraction level** — EKG Use Cases can represent entire
+ capability domains, not just individual interactions
+ - **Executability** — EKG Use Cases can be implemented as
+ executable models
+ - **Semantic packaging** — EKG Use Cases contain ontologies, data
+ products, and workflows, not just interaction descriptions
+ - **Tree organization** — EKG Use Cases are organized in a
+ hierarchical tree structure for governance and reuse
+ ### Microservices
+ **Microservices** architecture emphasizes building applications as
+ collections of small, independent services.
+ **Similarities:**
+
+ - **Modularity** — Both emphasize breaking down capabilities into
+ smaller, manageable components
+ - **Independence** — Both can be developed and deployed
+ independently
+ - **Composability** — Both can be composed to create larger systems
+
+ **Key Differences:**
+
+ - **Abstraction** — Use Cases operate at a business capability level,
+ while microservices operate at a technical service level
+ - **Semantics** — Use Cases are built on semantic models that
+ enable deeper integration
+ - **Business focus** — Use Cases are defined by business outcomes,
+ while microservices are defined by technical boundaries
+ - **Reusability** — Use Cases emphasize reuse of business logic,
+ data models, and workflows, not just code
+
+ ### Domain-Driven Design (DDD) Bounded Contexts
+
+ **Bounded Contexts** in Domain-Driven Design define the boundaries
+ within which a domain model is valid.
+
+ **Similarities:**
+
+ - **Domain boundaries** — Both define boundaries for business
+ concepts and logic
+ - **Contextual models** — Both recognize that the same concept can
+ have different meanings in different contexts
+ - **Business alignment** — Both align technical implementation with
+ business domains
+
+ **Key Differences:**
+
+ - **Scope** — Use Cases can span multiple bounded contexts or be
+ contained within one
+ - **Executability** — Use Cases can be captured as executable
+ models
+ - **Tree structure** — Use Cases are organized in a hierarchical
+ tree for governance
+ - **Reuse focus** — Use Cases emphasize reuse and composition across
+ contexts
+
+ ## Summary
+
+ While Use Cases in the Use Case Tree Method share concepts with these related
+ approaches, they are uniquely designed for the Enterprise Knowledge
+ Graph context:
+
+ - **Semantic foundation** enables deeper integration and
+ interoperability
+ - **Executable models** allow use cases to run directly in the EKG
+ - **Tree structure** provides governance and dependency management
+ - **Business-first approach** ensures alignment with business
+ outcomes and value
+
+=== "Ontology"
+
+ ## Ontology (minimal facts we can state today)
+
+ --8<-- "fragment/uctm-diagram-use-case.md"
+
+ We're not (yet) prescribing a full OWL ontology here.
+ But we can state a small set of **facts** that people can reliably use to build their own
+ ontology / schema / graph model around a Use Case.
+
+ ### Required facts about a Use Case
+
+ - **Opaque universally unique identifier**
+ - A Use Case must have an **opaque**, **universally unique** identifier.
+ - Prefer a random identifier such as **UUIDv4**.
+ - Represent it as a URI, for example:
+
+ `urn:uuid:550e8400-e29b-41d4-a716-446655440000`
+
+ - **Business-friendly name**
+ - A Use Case must have a **human-readable name** that resonates with business users.
+ - This is what people see, say, and search for.
+
+ - **Slug**
+ - A Use Case must have a **slug**: a kebab-cased identifier that is **at least unique
+ within the organization** (and stable over time as much as possible).
+ - Example: `customer-360`, `reduce-churn-risk`, `supplier-risk-monitoring`
+
+ - **Business-focused definition**
+ - A Use Case must have a **definition** that explains what it is, in business terms.
+ - Keep it implementation-agnostic: focus on intent and value, not solutions.
+
+ - **One or more outcomes**
+ - A Use Case must have **at least one Outcome** explaining *why it exists* and *what
+ contribution is expected*.
+ - Outcomes can represent **KPIs**, **goals**, **objectives**, **definitions of success**,
+ etc.
+ - What an Outcome *is exactly* is determined by its **stereotype** (e.g. KPI vs Goal),
+ but the key is to capture expected **short/mid/long-term outcomes**.
+
+ - **Outcome relationships (supports inheritance and contribution mapping)**
+ - Model the connection between a Use Case and an Outcome via a **relationship-object**
+ (not just a direct link).
+ - This enables a Use Case to relate to an Outcome it **owns**, and also enables a child
+ Use Case to **reference an Outcome defined on a parent Use Case** (inherited) and
+ capture *how the child contributes* to that desired Outcome.
+
+ - **Use Case stereotype (optional, organization-defined)**
+ - A Use Case can have a **Use Case Stereotype**.
+ - By default, the stereotype is simply “Use Case”.
+ - Many organizations use different type names for scopes that are effectively the same
+ concept in the Use Case Tree Method. A stereotype makes the Use Case **recognizable**
+ in the local language without changing the underlying model.
+ - Organizations can define **any number** of stereotypes and how they interrelate,
+ including constraints like “allowed parent stereotypes” and “allowed child stereotypes”.
+ - Examples:
+ - **Business Capability Area**: allows only Business Capability Domain as child
+ - **Business Capability Domain**: parent must be Business Capability Area; child must be Business Capability
+ - **Business Capability**: parent must be Business Capability Domain; child can be anything
+ - **Data Domain**
+ - **Technical Capability**
+ - **Business Component**
+ - **Architecture Component**
+ - **Module**
+ - **API Service**
+ - **Application**
+
+ - **Stories (optional, owned)**
+ - A Use Case can have **zero or more Stories**.
+ - The relationship is **part-of**: the Use Case **owns** its Stories.
+ - If the Use Case is deleted, its owned Stories are deleted as well.
+
+ - **Workflow definitions (optional, owned)**
+ - A Use Case can have **zero or more Workflows**.
+ - More precisely: these are **WorkflowDefinition** objects (the definition, not a run).
+ - The relationship is **part-of**: the Use Case **owns** its workflow definitions.
+ - If the Use Case is deleted, its owned workflow definitions are deleted as well.
+
+ - **Persona taxonomy (optional, SKOS scheme)**
+ - A Use Case can have **zero or one PersonaTaxonomy**.
+ - A PersonaTaxonomy is a `skos:ConceptScheme` that groups the Personas relevant for the
+ Use Case.
+ - Personas are `skos:Concept` and are members of exactly one PersonaTaxonomy via
+ `skos:inScheme`.
+
+ - **Concept vocabularies (optional, mixed)**
+ - A Use Case can have **zero or more relationships** to Concept Vocabularies.
+ - It may **reference an external** Concept Vocabulary, and/or **own a private** Concept
+ Vocabulary.
+ - A Concept Vocabulary contains **Concepts**.
+ - Stories relate to Concepts via a **relationship-object** that captures usage type:
+ - **Input Concept** — required/mandatory input parameter (or optional)
+ - **Output Concept** — definition of the output (often a shape/compound object)
+ - **Dependent Concept** — referenced in filters/constraints (e.g., SQL/SPARQL `WHERE`)
+
+ ### How it fits with Concepts & Terms
+
+ In the Use Case Tree Method, [Concepts & Terms](concept.md) capture the shared vocabulary
+ and intent.
+ Ontologies make that vocabulary **precise and machine-actionable** (identifiers, relations,
+ constraints, and alignment to standards).
+
+ Learn more in [Ontology](ontology.md).
+
+ ### Governance and reuse (pragmatic guidance)
+
+ - **Reuse first**: adopt/align to existing ontologies before creating new ones
+ - **Versioning**: track ontology/schema versions alongside the Use Case version
+ - **Change impact**: semantic changes can break queries, validation, and workflows
+ - **Interoperability**: shared semantics are a primary driver for cross-domain reuse
diff --git a/docs/concept/workflow.md b/docs/concept/workflow.md
index 332ae915..639de1ac 100644
--- a/docs/concept/workflow.md
+++ b/docs/concept/workflow.md
@@ -1,12 +1,363 @@
+---
+description: "A logical sequence of steps that defines the order of execution for Stories within a Use Case to achieve desired business Outcomes. Learn how workflows structure business processes in the Use Case Tree Method."
+keywords:
+ - workflow
+ - business process
+ - process flow
+ - EKG method
+ - enterprise knowledge graph
+ - business automation
+schema_type: "Article"
+---
+
# Workflow
-Every [Use Case](use-case.md) has one or more Workflows.
+
+_A logical sequence of steps that defines the order of execution for
+Stories within a Use Case to achieve desired business Outcomes_
+
+
+=== "Business & Management Audience"
+
+ ## What Is a Workflow?
+
+ A **Workflow** defines the logical order of steps needed to
+ accomplish a business process within a [Use Case](use-case.md).
+ Every Use Case has one or more Workflows that describe how
+ business activities should be performed.
+
+ Workflows provide a structured way to organize and sequence the
+ work that needs to be done, ensuring that tasks are performed in
+ the right order and that dependencies are respected.
+
+ ## Why Workflows Matter
+
+ Workflows enable:
+
+ - **Clarity** — Everyone understands the sequence of activities
+ needed to accomplish a goal
+ - **Consistency** — The same process is followed every time,
+ reducing errors and variability
+ - **Efficiency** — Workflows optimize the order of operations
+ - **Automation** — Well-defined workflows can be automated,
+ reducing manual effort
+ - **Governance** — Workflows ensure that business rules and
+ policies are followed
+
+ !!! tip "Start with business logic"
+
+ Workflows should reflect how the business actually works, not
+ how systems are currently implemented.
+ Focus on the logical order of business activities.
+
+ ## Workflow Structure
+
+ Workflows consist of a sequence of steps, where each step
+ corresponds to executing a [Story](story.md) in the use case.
+ The steps are organized to achieve the desired business
+ [Outcome](outcome.md).
+
+ The concepts and terms used in the workflow are based on the
+ context-specific vocabulary identified during the requirements
+ gathering phase — the same [Concepts](concept.md) that define
+ the use case's domain.
+
+ ## When Are Workflows Defined?
+
+ Workflows are typically defined in later stages of the use case
+ lifecycle, once:
+
+ - The use case requirements are well understood
+ - The Stories are clearly defined
+ - The logical order of activities is known
+ - Dependencies between activities are identified
+
+ This allows workflows to be designed based on a solid
+ understanding of what needs to be accomplished and how.
+
+=== "Data & Tech Audience"
+
+ ## What Is a Workflow in the Use Case Tree Method?
+
+ A **Workflow** is a logical sequence of steps that defines the
+ order of execution for [Stories](story.md) within a [Use
+ Case](use-case.md).
+ Every Use Case has one or more Workflows that describe how
+ business processes should be executed.
+
+ Workflows depend on the [Concepts](concept.md) captured during
+ the requirements gathering phase and are executed to achieve the
+ desired business [Outcome](outcome.md).
+
+ ## Workflow Components
+
+ Workflows consist of:
+
+ - **Steps** — Each step corresponds to executing a Story in the
+ use case
+ - **Sequence** — The logical order in which steps should be
+ executed
+ - **Dependencies** — Relationships between steps that determine
+ execution order
+ - **Concepts** — The domain concepts and terms used throughout
+ the workflow
+
+ The concepts and terms used in the workflow are based on the
+ context-specific vocabulary identified during the requirements
+ gathering phase — the same Concepts that define the use case's
+ domain.
+
+ ## Relationship to Stories
+
+ Each step in a workflow corresponds to executing a Story in the
+ use case.
+ This means:
+
+ - **Stories define what** — Each Story specifies what needs to
+ be accomplished (the capability)
+ - **Workflows define how** — Workflows specify the order and
+ sequence in which Stories are executed
+ - **Together they define the process** — Stories + Workflows =
+ Complete business process definition
+
+ This separation allows Stories to be reusable across different
+ workflows, while workflows can compose Stories in different ways
+ to achieve different outcomes.
+
+ **Bidirectional relationship:**
+ For each Story, we always know in which Workflows it participates
+ as a Step.
+ This bidirectional relationship enables:
+
+ - **Story reuse analysis** — Understanding which workflows use a
+ given story
+ - **Impact analysis** — Knowing what workflows are affected when
+ a story changes
+ - **Discovery** — Finding workflows that accomplish similar
+ outcomes by examining their constituent stories
+
+ ## Workflow Execution
+
+ Workflows can be executed in different ways:
+
+ - **Manual execution** — Steps are performed by people following
+ the workflow definition
+ - **Automated execution** — Steps are performed by systems that
+ interpret and execute the workflow
+ - **Hybrid execution** — Some steps are automated, others are
+ manual
+
+ The EKG can track workflow execution, monitor progress, and
+ ensure that business rules and policies are followed throughout
+ the process.
+
+ ## Persistent Stateful Workflows
+
+ It is expected that workflows have **persistent stateful**
+ execution capabilities.
+ This means that workflows can maintain their state across
+ execution sessions, enabling them to handle processes of varying
+ durations and complexity.
+
+ **Short-duration workflows:**
+ Some workflows can be done quickly in real-time and in-memory,
+ where one [Story's](story.md) output can be directly used as the
+ next Story's input.
+ These workflows execute entirely within a single session and
+ complete in seconds or minutes.
+
+ **Long-duration workflows:**
+ Some workflows may take hours, weeks, or even months to complete.
+ These workflows require persistent state management because:
+
+ - **Human involvement** — Steps may require human review,
+ approval, or input, which can take significant time
+ - **Agentic steps** — Steps may involve autonomous agents that
+ need time to complete their tasks
+ - **External dependencies** — Steps may depend on external
+ systems or events that occur over extended periods
+ - **Complex processes** — Business processes may naturally span
+ long timeframes (e.g., procurement, project management,
+ regulatory approvals)
+
+ Persistent stateful workflows enable the EKG to:
+
+ - **Resume execution** — Workflows can pause and resume from
+ their last state
+ - **Track progress** — Long-running workflows maintain their
+ state and can report progress at any time
+ - **Handle interruptions** — Workflows can handle system
+ restarts, failures, or pauses without losing their state
+ - **Support human-in-the-loop** — Workflows can wait for human
+ input and resume when that input is provided
+
+ This capability is essential for modeling real-world business
+ processes that don't complete instantly but unfold over time.
+
+ ## Workflows as First-Class EKG Objects
+
+ Ideally, workflows are persisted as part of the overall EKG as
+ **first-class citizen objects**.
+ This means that workflows, their steps, and their states can be
+ inspected, queried, and reasoned about like any other object in
+ the Enterprise Knowledge Graph.
+
+ **Workflow lifecycle:**
+
+ - **Workflows are initiated by Stories** — A Story can trigger
+ the execution of a workflow
+ - **Each step is a call to a Story** — Each step in a workflow
+ corresponds to executing a Story, maintaining the connection
+ between the workflow definition and the business requirements
+ - **State is persisted** — Workflow state is stored in the EKG,
+ enabling inspection, monitoring, and reasoning about workflow
+ execution
+
+ **Benefits of first-class persistence:**
+
+ - **Inspectability** — Workflow steps and states can be queried
+ and analyzed like any other EKG data
+ - **Observability** — Workflow execution can be monitored and
+ traced through the EKG
+ - **Reasoning** — The EKG can reason about workflow state,
+ dependencies, and execution paths
+ - **Integration** — Workflows are integrated with other EKG
+ concepts (Use Cases, Stories, Concepts, Personas)
+
+ **Implementation:**
+ Conceptually, workflows are similar to
+ [AWS Step Functions](https://aws.amazon.com/step-functions/),
+ which could be one of the technologies used to implement these
+ workflows.
+ However, the key difference is that in the Use Case Tree Method, workflows
+ are not just execution engines but semantic objects that are part
+ of the knowledge graph itself, enabling deeper integration and
+ reasoning capabilities.
+
+ !!! info "Provenance"
+
+ When your EKG Service Layer fully supports the Use Case Tree Method and
+ you have a Story Service that can execute Stories, then
+ ideally you want it to automatically maintain the provenance
+ chain of activities.
+
+ Like the [PROV-O](https://www.w3.org/TR/prov-o/) (Provenance
+ Ontology) describes, provenance has three main classes:
+ **Activity**, **Agent**, and **Entity**.
+
+ The ultimate form of provenance implementation is to be able
+ to link an Activity to the execution of a particular Story in
+ the context of a particular instance of a Workflow.
+ Then you have everything to provide full explainability.
+
+ This provenance chain enables:
+
+ - **Traceability** — Understanding what happened and why
+ - **Explainability** — Explaining how results were produced
+ - **Auditability** — Tracking who did what and when
+ - **Debugging** — Understanding execution paths and failures
+
+ !!! tip "Observability"
+
+ In modern-day architectures, you have fully instrumented code
+ producing traces that are collected by
+ [OpenTelemetry](https://opentelemetry.io/) (OTEL)-compliant
+ collectors.
+
+ The concept of a so-called **"span"** (in
+ [OTLP](https://opentelemetry.io/docs/specs/otlp/) / OTEL
+ jargon) perfectly aligns with a
+ [PROV-O](https://www.w3.org/TR/prov-o/) Activity and with a
+ Workflow-step execution.
+
+ This alignment enables:
+
+ - **Unified observability** — Workflow execution traces can
+ be integrated with application traces
+ - **End-to-end visibility** — From business process
+ (Workflow) to technical implementation (code spans)
+ - **Semantic enrichment** — OTEL spans can be enriched with
+ EKG semantic metadata (Story, Workflow, Persona, etc.)
+ - **Cross-system correlation** — Linking business activities
+ with technical execution across distributed systems
+
+ ## Workflow Patterns
+
+ Common workflow patterns include:
+
+ - **Sequential** — Steps execute one after another in a fixed
+ order
+ - **Parallel** — Multiple steps execute simultaneously
+ - **Conditional** — Different steps execute based on conditions
+ - **Iterative** — Steps repeat until a condition is met
+ - **Event-driven** — Steps execute in response to events
+
+ These patterns can be combined to create complex workflows that
+ model real-world business processes.
+
+ ## Relationship to Other Concepts
+
+ Workflows relate to other core concepts:
+
+ - **[Use Cases](use-case.md)** — Every use case has one or more
+ workflows
+ - **[Stories](story.md)** — Each workflow step corresponds to
+ executing a story
+ - **[Concepts](concept.md)** — Workflows use concepts from the
+ use case's vocabulary
+ - **[Outcomes](outcome.md)** — Workflows are executed to achieve
+ desired business outcomes
+ - **[Personas](persona.md)** — Workflows specify which personas
+ are involved in each step
+
+ This integration ensures that workflows are not isolated process
+ definitions but part of a cohesive, semantic model of the
+ enterprise.
+
+=== "Ontology"
+
+ ## Ontology (minimal facts we can state today)
+
+ --8<-- "fragment/uctm-diagram-workflow.md"
+
+ We're not (yet) prescribing a full OWL ontology here.
+ But we can state a small set of **facts** that people can reliably use to build their own
+ ontology / schema / graph model around a Workflow.
+
+ !!! note "WorkflowDefinition"
+
+ When we say “Workflow” here, we primarily mean the **definition** of a workflow
+ (a **WorkflowDefinition**), not a specific runtime execution instance.
+
+ ### Required facts about a WorkflowDefinition
+
+ - **Opaque universally unique identifier**
+ - A WorkflowDefinition should have an **opaque**, **universally unique** identifier.
+ - Prefer a random identifier such as **UUIDv4**, represented as a URI:
+ `urn:uuid:550e8400-e29b-41d4-a716-446655440000`
+
+ - **Business-friendly name**
+ - A WorkflowDefinition should have a human-readable name.
+
+ - **Slug**
+ - A WorkflowDefinition should have a kebab-cased slug that is unique at least within the
+ organization.
+ - Example: `onboard-supplier`, `assess-counterparty-risk`
+
+ - **Definition**
+ - A WorkflowDefinition should have a definition describing the business process it models.
+
+ - **Owned by a Use Case**
+ - A WorkflowDefinition is **part-of** a Use Case: the Use Case **owns** it.
+ - If the owning Use Case is deleted, its workflow definitions are deleted as well.
+
+ - **Steps that reference Stories (relationship-object)**
+ - A WorkflowDefinition has **zero or more Steps**.
+ - Each Step references a Story.
+ - Model Steps as relationship-objects so you can capture ordering and execution semantics
+ (sequence, branching/conditions, parallelism, retries, etc.).
-For every given use case, we also need to describe the logical order
-of things in terms of workflows or business processes.
-These workflows depend on the [concepts](./concept.md) captured during
-the requirements gathering phase and are executed to achieve the desired
-business [outcome](./outcome.md).
-Each step in the workflow corresponds to executing a story in the use case,
-and the concepts and terms used in the workflow are based on the
-context-specific vocabulary identified during the requirements gathering phase.
+ - **Outcomes and concepts**
+ - Workflows are executed to achieve Outcomes (directly or via the Stories they orchestrate).
+ - Workflows use Concepts through the Use Case’s Concept Vocabularies and the Stories in
+ their steps.
diff --git a/docs/diagrams/src/persona-class-diagram.puml b/docs/diagrams/src/persona-class-diagram.puml
deleted file mode 100644
index 4287ae92..00000000
--- a/docs/diagrams/src/persona-class-diagram.puml
+++ /dev/null
@@ -1,27 +0,0 @@
-!option handwritten false
-@startuml
-!include ../include/themes/light.puml
-
-class Concept {
- - type : ConceptType
-}
-class Concept [[http://plantuml.com{Optional tooltip} This label is printed]]
-class UseCase {
- - vocabulary: Vocabulary
- - stories: Story[]
-}
-UseCase --> UseCase : requires
-Vocabulary "*" --> "*" Concept
-Vocabulary "*" --> "*" Term
-Story --> "*" Concept : input
-Story --> "*" Concept : output
-Term --> "1..*" Concept
-Concept ---right-> OntologyAxiom
-Vocabulary <--> Concept
-UseCase --> "1..*" Story
-Persona --up-|> Concept
-Concept --> Concept : broader
-Concept --> Term : preferred
-UseCase --> "1" Vocabulary : use case vocabulary
-Persona "1" -right-o "0..*" Story
-@enduml
diff --git a/docs/fragment/uctm-diagram-concept.md b/docs/fragment/uctm-diagram-concept.md
new file mode 100644
index 00000000..3689928c
--- /dev/null
+++ b/docs/fragment/uctm-diagram-concept.md
@@ -0,0 +1,36 @@
+
+
+```mermaid
+classDiagram
+ direction LR
+ hide members
+
+ class Concept
+ class Term
+ class BusinessTerm
+ class TechnicalTerm
+ class ConceptVocabulary
+ class UseCase
+ class Story
+ class StoryConceptRelationship
+
+ %% Term specializations
+ Term <|-- BusinessTerm
+ Term <|-- TechnicalTerm
+
+ %% Terms
+ Concept "1" *-- "1..*" Term : ∶term
+ Concept "0..1" --> "1" BusinessTerm : ∶labelTerm
+
+ %% Vocabularies
+ %% Mermaid classDiagram can't parse ASCII ':' inside labels; use ratio sign (∶) instead.
+ ConceptVocabulary "1" o-- "0..*" Concept : skos∶inScheme
+ ConceptVocabulary "0..*" --> "1" UseCase : ∶useCase
+
+ %% Usage
+ Story "0..*" --> "1" StoryConceptRelationship : ∶storyConcept
+ StoryConceptRelationship --> Concept : ∶concept
+```
+
+
+
diff --git a/docs/fragment/uctm-diagram-outcome.md b/docs/fragment/uctm-diagram-outcome.md
new file mode 100644
index 00000000..f3331586
--- /dev/null
+++ b/docs/fragment/uctm-diagram-outcome.md
@@ -0,0 +1,23 @@
+
+
+```mermaid
+classDiagram
+ direction LR
+ hide members
+
+ class Outcome
+ class UseCase
+ class Story
+ class OutcomeRelationship
+
+ %% Outcome linkage (relationship-object)
+ OutcomeRelationship "0..*" --> "1" UseCase : ∶useCase
+ OutcomeRelationship --> Outcome : ∶targetOutcome
+
+ %% Stories reference outcomes as "why"
+ %% Mermaid classDiagram can't parse ASCII ':' inside labels; use ratio sign (∶) instead.
+ Story --> Outcome : ∶contributesTo
+```
+
+
+
diff --git a/docs/fragment/uctm-diagram-persona.md b/docs/fragment/uctm-diagram-persona.md
new file mode 100644
index 00000000..82d57fa8
--- /dev/null
+++ b/docs/fragment/uctm-diagram-persona.md
@@ -0,0 +1,26 @@
+
+
+```mermaid
+classDiagram
+ direction LR
+ hide members
+
+ class Persona
+ class Story
+ class UseCase
+ class PersonaTaxonomy
+
+ %% Personas show up in stories ("playedBy") which are owned by a use case
+ Story --> Persona : ∶playedBy
+ Story "0..*" --> "1" UseCase : ∶useCase
+
+ %% Personas belong to a PersonaTaxonomy (SKOS concept scheme)
+ Persona --> PersonaTaxonomy : skos∶inScheme
+ PersonaTaxonomy "0..1" --> "1" UseCase : ∶useCase
+
+ %% Persona inheritance (optional)
+ Persona --> Persona : ∶isSubPersonaOf
+```
+
+
+
diff --git a/docs/fragment/uctm-diagram-story.md b/docs/fragment/uctm-diagram-story.md
new file mode 100644
index 00000000..40d08966
--- /dev/null
+++ b/docs/fragment/uctm-diagram-story.md
@@ -0,0 +1,40 @@
+
+
+```mermaid
+classDiagram
+ direction LR
+ hide members
+
+ class Story
+ class UseCase
+ class Persona
+ class Outcome
+ class Concept
+ class Term
+ class BusinessTerm
+ class TechnicalTerm
+ class WorkflowDefinition
+ class StoryConceptRelationship
+
+ %% Term specializations
+ Term <|-- BusinessTerm
+ Term <|-- TechnicalTerm
+
+ %% Other resources point to UseCase (typical KG modeling style)
+ Story "0..*" --> "1" UseCase : ∶useCase
+
+ %% Story structure
+ Story --> Persona : ∶playedBy
+ Story --> Outcome : ∶contributesTo
+
+ %% Concept usage
+ Story "0..*" --> "1" StoryConceptRelationship : ∶storyConcept
+ StoryConceptRelationship --> Concept : ∶concept
+ Concept "1" *-- "1..*" Term : ∶term
+ Concept "0..1" --> "1" BusinessTerm : ∶labelTerm
+
+ %% Workflow participation
+ WorkflowDefinition --> Story : ∶steps
+```
+
+
diff --git a/docs/fragment/uctm-diagram-term.md b/docs/fragment/uctm-diagram-term.md
new file mode 100644
index 00000000..a2a38687
--- /dev/null
+++ b/docs/fragment/uctm-diagram-term.md
@@ -0,0 +1,30 @@
+
+
+```mermaid
+classDiagram
+ direction LR
+ hide members
+
+ class Term
+ class BusinessTerm
+ class TechnicalTerm
+ class Concept
+ class ConceptVocabulary
+ class UseCase
+
+ %% Term specializations
+ Term <|-- BusinessTerm
+ Term <|-- TechnicalTerm
+
+ %% Ownership
+ Concept "1" *-- "1..*" Term : ∶term
+ Concept "0..1" --> "1" BusinessTerm : ∶labelTerm
+
+ %% Context (terms live inside vocabularies used by use cases)
+ %% Mermaid classDiagram can't parse ASCII ':' inside labels; use ratio sign (∶) instead.
+ ConceptVocabulary "1" o-- "0..*" Concept : skos∶inScheme
+ ConceptVocabulary "0..*" --> "1" UseCase : ∶useCase
+```
+
+
+
diff --git a/docs/fragment/uctm-diagram-use-case.md b/docs/fragment/uctm-diagram-use-case.md
new file mode 100644
index 00000000..1e3a2a49
--- /dev/null
+++ b/docs/fragment/uctm-diagram-use-case.md
@@ -0,0 +1,56 @@
+
+
+```mermaid
+classDiagram
+ direction LR
+ hide members
+
+ class UseCase
+ class UseCaseStereotype
+ class Story
+ class WorkflowDefinition
+ class Outcome
+ class OutcomeRelationship
+ class ConceptVocabulary
+ class Concept
+ class Term
+ class BusinessTerm
+ class TechnicalTerm
+ class Persona
+ class StoryConceptRelationship
+ class PersonaTaxonomy
+
+ %% Term specializations
+ Term <|-- BusinessTerm
+ Term <|-- TechnicalTerm
+
+ %% Other resources point to UseCase (typical KG modeling style)
+ Story "0..*" --> "1" UseCase : ∶useCase
+ WorkflowDefinition "0..*" --> "1" UseCase : ∶useCase
+ ConceptVocabulary "0..*" --> "1" UseCase : ∶useCase
+ OutcomeRelationship "0..*" --> "1" UseCase : ∶useCase
+ PersonaTaxonomy "0..1" --> "1" UseCase : ∶useCase
+
+ %% Local ownership / containment
+ Concept "1" *-- "1..*" Term : ∶term
+ Concept "0..1" --> "1" BusinessTerm : ∶labelTerm
+ %% Mermaid classDiagram can't parse ASCII ':' inside labels; use ratio sign (∶) instead.
+ ConceptVocabulary "1" o-- "0..*" Concept : skos∶inScheme
+
+ %% Other key relationships
+ UseCase "0..1" --> "1" UseCaseStereotype : usecase∶stereotype
+ OutcomeRelationship --> Outcome : ∶targetOutcome
+
+ %% Usage (high-level)
+ Story --> Persona : ∶playedBy
+ Story --> Outcome : ∶contributesTo
+ Story "0..*" --> "1" StoryConceptRelationship : ∶storyConcept
+ StoryConceptRelationship --> Concept : ∶concept
+ WorkflowDefinition --> Story : steps
+
+ %% Personas belong to a PersonaTaxonomy (SKOS concept scheme)
+ Persona --> PersonaTaxonomy : skos∶inScheme
+```
+
+
+
diff --git a/docs/fragment/uctm-diagram-workflow.md b/docs/fragment/uctm-diagram-workflow.md
new file mode 100644
index 00000000..14f8399c
--- /dev/null
+++ b/docs/fragment/uctm-diagram-workflow.md
@@ -0,0 +1,28 @@
+
+
+```mermaid
+classDiagram
+ direction LR
+ hide members
+
+ class WorkflowDefinition
+ class UseCase
+ class Story
+ class Outcome
+ class Concept
+ class StoryConceptRelationship
+
+ %% Other resources point to UseCase (typical KG modeling style)
+ WorkflowDefinition "0..*" --> "1" UseCase : ∶useCase
+
+ %% Steps (relationship-object implied)
+ WorkflowDefinition --> Story : ∶steps
+
+ %% Stories link to outcomes and concepts
+ Story --> Outcome : ∶contributesTo
+ Story "0..*" --> "1" StoryConceptRelationship : ∶storyConcept
+ StoryConceptRelationship --> Concept : ∶concept
+```
+
+
+
diff --git a/docs/fragment/uctm-partial-class-diagram.md b/docs/fragment/uctm-partial-class-diagram.md
new file mode 100644
index 00000000..71ac544b
--- /dev/null
+++ b/docs/fragment/uctm-partial-class-diagram.md
@@ -0,0 +1,45 @@
+
+
+```mermaid
+classDiagram
+ direction LR
+ hide members
+
+ class UseCase
+
+ class UseCaseStereotype
+
+ class Story
+
+ class WorkflowDefinition
+
+ class Outcome
+
+ class OutcomeRelationship
+
+ class Concept
+
+ class ConceptVocabulary
+ class Term
+ class Persona
+
+ %% Ownership / composition (part-of)
+ UseCase "1" *-- "0..*" Story : owns
+ UseCase "1" *-- "0..*" WorkflowDefinition : owns
+ Concept "1" *-- "1..*" Term : owns
+
+ %% Relationships
+ UseCase "0..1" --> "1" UseCaseStereotype : hasStereotype
+ UseCase "0..*" --> "0..*" OutcomeRelationship : outcomeLink
+ OutcomeRelationship --> Outcome : targetOutcome
+ UseCase "0..*" --> "0..*" ConceptVocabulary : references/owns
+ ConceptVocabulary "1" o-- "0..*" Concept : contains
+
+ %% Usage
+ Story --> Persona : story:playedBy
+ Story --> Outcome : story:contributesTo
+ Story --> StoryConceptRelationship : story∶relatedConcept
+ StoryConceptRelationship --> Concept: story∶concept
+ WorkflowDefinition --> Story : workflow:firstStep
+```
+
diff --git a/docs/index.md b/docs/index.md
index 8866e071..860c1b85 100644
--- a/docs/index.md
+++ b/docs/index.md
@@ -1,4 +1,12 @@
---
+description: "Use Case Tree Method for developing Enterprise Knowledge Graphs (EKG). A comprehensive method to develop business capabilities through structured use cases, outcomes, and workflows."
+keywords:
+ - EKG method
+ - enterprise knowledge graph
+ - use case tree
+ - business capabilities
+ - knowledge graph methodology
+schema_type: "WebSite"
hide:
- navigation
- toc
diff --git a/docs/intro/index.md b/docs/intro/index.md
index 018d1a6b..9eac441a 100644
--- a/docs/intro/index.md
+++ b/docs/intro/index.md
@@ -4,6 +4,14 @@ author:
hide:
- toc
- navigation
+description: "Introduction to the Use Case Tree Method for developing Enterprise Knowledge Graphs. Learn how this method enables strategic use cases, data quality, compliance, and competitive advantage."
+keywords:
+ - use case tree method
+ - EKG introduction
+ - enterprise knowledge graph method
+ - business capabilities
+ - EKG method
+schema_type: "Article"
---
# Use Case Tree Method for Business Capabilities
diff --git a/docs/javascript/images_dark.js b/docs/javascript/images_dark.js
deleted file mode 100644
index 39f6314f..00000000
--- a/docs/javascript/images_dark.js
+++ /dev/null
@@ -1,91 +0,0 @@
-const paletteSwitcher1 = document.getElementById("__palette_1");
-const paletteSwitcher2 = document.getElementById("__palette_2");
-
-paletteSwitcher1.addEventListener("change", function () {
- documentFromDarkToLight(document)
-});
-
-paletteSwitcher2.addEventListener("change", function () {
- documentFromLightToDark(document)
-});
-
-if (window.matchMedia && window.matchMedia('(prefers-color-scheme: dark)').matches) {
- alert("you're in dark mode") // dark mode
-} else {
- alert("you're in light mode")
-}
-
-window.matchMedia('(prefers-color-scheme: dark)').addEventListener('change', e => {
- const newColorScheme = e.matches ? "dark" : "light";
- alert("zzzzz " + newColorScheme)
-});
-
-document.addEventListener("DOMContentLoaded", function(){
- alert('The page has fully loaded');
- const palette = __md_get("__palette");
- alert("palette: " + palette)
- if (palette && typeof palette.color === "object")
- if (palette.color.scheme === "slate") {
- alert("dark: " + palette.color.scheme)
- }
- }
-});
-
-
-// if (window.matchMedia('(prefers-color-scheme: dark)').matches === true) {
-// documentFromLightToDark(document)
-// }
-
-const darkModeMediaQuery = window.matchMedia('(prefers-color-scheme: dark)');
-darkModeMediaQuery.addListener((e) => {
- const darkModeOn = e.matches;
-
- if (darkModeOn)
- documentFromLightToDark(document)
- else
- documentFromDarkToLight(document)
- console.log(`Dark mode is ${darkModeOn ? '🌒 on' : '☀️ off'}.`);
-});
-
-function documentFromDarkToLight(document) {
- imagesFromDarkToLight(document.querySelectorAll('img[src$="darkable"'));
- objectsFromDarkToLight(document.querySelectorAll('object[data$="darkable"'));
-}
-
-function documentFromLightToDark(document) {
- imagesFromLightToDark(document.querySelectorAll('img[src$="darkable"'));
- objectsFromLightToDark(document.querySelectorAll('object[data$="darkable"'));
-}
-
-function imagesFromLightToDark(images) {
- images.forEach(image => {
- const idx = image.src.lastIndexOf('.');
- if (idx > -1) {
- const add = "_dark";
- image.src = [image.src.slice(0, idx), add, image.src.slice(idx)].join('');
- }
- });
-}
-
-function imagesFromDarkToLight(images) {
- images.forEach(image => {
- image.src = image.src.replace("_dark", "");
- });
-}
-
-function objectsFromLightToDark(objects) {
- objects.forEach(object => {
- const idx = object.data.lastIndexOf('.');
- if (idx > -1) {
- const add = "_dark";
- object.data = [object.data.slice(0, idx), add, object.data.slice(idx)].join('');
- }
- });
-}
-
-function objectsFromDarkToLight(objects) {
- objects.forEach(object => {
- object.data = object.data.replace("_dark", "");
- });
-}
-
diff --git a/docs/javascript/refresh_on_toggle_dark_light.js b/docs/javascript/refresh_on_toggle_dark_light.js
deleted file mode 100644
index a5b7fa7e..00000000
--- a/docs/javascript/refresh_on_toggle_dark_light.js
+++ /dev/null
@@ -1,10 +0,0 @@
-const paletteSwitcher1 = document.getElementById("__palette_1");
-const paletteSwitcher2 = document.getElementById("__palette_2");
-
-paletteSwitcher1.addEventListener("change", function () {
- location.reload();
-});
-
-paletteSwitcher2.addEventListener("change", function () {
- location.reload();
-});
\ No newline at end of file
diff --git a/docs/javascripts/mermaid.js b/docs/javascripts/mermaid.js
new file mode 100644
index 00000000..53a5fbe1
--- /dev/null
+++ b/docs/javascripts/mermaid.js
@@ -0,0 +1,48 @@
+/**
+ * Mermaid.js Configuration for EKGF Custom Colors
+ *
+ * IMPORTANT:
+ * - We use Material for MkDocs' NATIVE Mermaid support (NOT mkdocs-mermaid2-plugin!)
+ * - Do NOT install mkdocs-mermaid2-plugin - it conflicts with Material's native support
+ * - Material for MkDocs automatically looks for window.mermaidConfig in extra_javascript files
+ * - This configuration applies to all Mermaid diagrams site-wide
+ *
+ * Color Scheme (EKGF Brand):
+ * - Primary: #4051b5 (Indigo blue) - node backgrounds
+ * - Accent: #ff6f00 (EKGF orange) - borders and connector lines
+ * - Text: #ffffff (White) - for contrast on colored nodes
+ *
+ * How It Works:
+ * 1. Material for MkDocs reads window.mermaidConfig before initializing Mermaid
+ * 2. This file is loaded via extra_javascript in mkdocs.yml
+ * 3. The theme variables override Material's defaults
+ * 4. No need for inline %%{init}%% directives in diagrams
+ */
+
+window.mermaidConfig = {
+ theme: 'base',
+ themeVariables: {
+ primaryColor: '#4051b5',
+ primaryTextColor: '#ffffff',
+ primaryBorderColor: '#ff6f00',
+ lineColor: '#ff6f00',
+ secondaryColor: '#4051b5',
+ secondaryTextColor: '#ffffff',
+ secondaryBorderColor: '#ff6f00',
+ tertiaryColor: '#4051b5',
+ tertiaryTextColor: '#ffffff',
+ tertiaryBorderColor: '#ff6f00',
+ background: '#ffffff',
+ mainBkg: '#4051b5',
+ secondaryBkg: '#4051b5',
+ tertiaryBkg: '#4051b5',
+ textColor: '#ffffff',
+ nodeBorder: '#ff6f00',
+ clusterBkg: '#4051b5',
+ clusterBorder: '#ff6f00',
+ defaultLinkColor: '#ff6f00',
+ titleColor: '#333333',
+ edgeLabelBackground: '#ffffff'
+ }
+};
+
diff --git a/docs/objective/.pages.yaml b/docs/objective/.pages.yaml
index 5088bcc9..54674233 100644
--- a/docs/objective/.pages.yaml
+++ b/docs/objective/.pages.yaml
@@ -1,16 +1,16 @@
title: Objectives
nav:
- - Composable Business: composable-business.md
- - Requirements Captured: know-what-the-business-wants.md
- - Knowledge Captured: capture-knowledge.md
- - Gaps Bridged: bridge-the-gap.md
- - Expectations Managed: manage-expectations.md
- - Did not boil the ocean: avoid-boiling-the-ocean.md
- - Disruption Avoided: avoid-disruption.md
- - Quality Increased: increase-quality.md
- - Aligned with Strategy: align-with-business-strategy.md
- - Delivered: strategic-usecases.md
- - Modularity Managed: modularity.md
- - Interoperability Achieved: interoperability.md
- - Reuse Enabled: enable-reuse.md
+ - "A: Interoperability Achieved": interoperability.md
+ - "B: Composable Business": composable-business.md
+ - "C: Requirements Captured": know-what-the-business-wants.md
+ - "D: Knowledge Captured": capture-knowledge.md
+ - "E: Gaps Bridged": bridge-the-gap.md
+ - "F: Expectations Managed": manage-expectations.md
+ - "G: Did not boil the ocean": avoid-boiling-the-ocean.md
+ - "H: Disruption Avoided": avoid-disruption.md
+ - "I: Quality Increased": increase-quality.md
+ - "J: Aligned with Strategy": align-with-business-strategy.md
+ - "K: Delivered": strategic-usecases.md
+ - "L: Modularity Managed": modularity.md
+ - "M: Reuse Enabled": enable-reuse.md
- ...
diff --git a/docs/objective/align-with-business-strategy.md b/docs/objective/align-with-business-strategy.md
index 2f5ea469..093ddba8 100644
--- a/docs/objective/align-with-business-strategy.md
+++ b/docs/objective/align-with-business-strategy.md
@@ -1,11 +1,20 @@
---
-title: Align with Business Strategy
+title: "J: Align with Business Strategy"
authors:
- Jacobus Geluk
hide:
- - toc
+- toc
+description: "Align strategy of business capability improvement and execution. Learn how the Use Case Tree Method creates a single artifact that aligns all lines of business."
+keywords:
+ - business strategy
+ - strategic alignment
+ - business capabilities
+ - EKG method
+ - enterprise knowledge graph
+ - capability planning
+schema_type: "Article"
---
-# Align with Business Strategy
+# J: Align with Business Strategy
_Align strategy of business capability improvement and execution._
diff --git a/docs/objective/avoid-boiling-the-ocean.md b/docs/objective/avoid-boiling-the-ocean.md
index d9605e8a..7d9adad4 100644
--- a/docs/objective/avoid-boiling-the-ocean.md
+++ b/docs/objective/avoid-boiling-the-ocean.md
@@ -1,11 +1,20 @@
---
-title: Avoid "boiling the ocean"
+title: "G: Avoid \"boiling the ocean\""
authors:
- Jacobus Geluk
hide:
- - toc
+- toc
+description: "Provide focus, clarity, deliver business value fast, do the right things at the right time. Learn how the Use Case Tree Method prevents scope creep and delivers value incrementally."
+keywords:
+ - scope management
+ - incremental delivery
+ - business value
+ - EKG method
+ - enterprise knowledge graph
+ - agile methodology
+schema_type: "Article"
---
-# Avoid "boiling the ocean"
+# G: Avoid "boiling the ocean"
_Provide focus, clarity, deliver business value fast, do the right things at the right time. Save money._
diff --git a/docs/objective/avoid-disruption.md b/docs/objective/avoid-disruption.md
index 63ad21f2..30064f72 100644
--- a/docs/objective/avoid-disruption.md
+++ b/docs/objective/avoid-disruption.md
@@ -1,11 +1,20 @@
---
-title: Avoid Disruption
+title: "H: Avoid Disruption"
authors:
- Jacobus Geluk
hide:
- - toc
+- toc
+description: "Make changes gradually with clear interdependencies to avoid disruption across use cases. Learn how the Use Case Tree Method enables safe, incremental change."
+keywords:
+ - change management
+ - disruption avoidance
+ - incremental change
+ - EKG method
+ - enterprise knowledge graph
+ - use case dependencies
+schema_type: "Article"
---
-# Avoid Disruption
+# H: Avoid Disruption
_Make changes gradually with clear interdependencies to avoid disruption across use cases._
diff --git a/docs/objective/bridge-the-gap.md b/docs/objective/bridge-the-gap.md
index 04656301..1253dfdf 100644
--- a/docs/objective/bridge-the-gap.md
+++ b/docs/objective/bridge-the-gap.md
@@ -1,14 +1,23 @@
---
-title: Bridge the traditional gap between Business & Technology
+title: "E: Bridge the traditional gap between Business & Technology"
authors:
- Jacobus Geluk
-hide:
+hide:
- toc
+description: "Align business expectations with technology delivery. Learn how the Use Case Tree Method bridges the gap between business and IT through continuous engagement."
+keywords:
+ - business IT alignment
+ - business technology gap
+ - stakeholder engagement
+ - EKG method
+ - enterprise knowledge graph
+ - product owner
+schema_type: "Article"
---
-# Bridge the traditional gap between Business & Technology
+# E: Bridge the traditional gap between Business & Technology
-Align business expectations with technology delivery.
+_Align business expectations with technology delivery._
- Engage with the business, the product owner and get continuous
diff --git a/docs/objective/capture-knowledge.md b/docs/objective/capture-knowledge.md
index 04905cd4..1a27fcf9 100644
--- a/docs/objective/capture-knowledge.md
+++ b/docs/objective/capture-knowledge.md
@@ -1,11 +1,20 @@
---
-title: Capture Knowledge
+title: "D: Capture Knowledge"
authors:
- Jacobus Geluk
hide:
- toc
+description: "Enabling a whole new league of use cases through comprehensive knowledge capture. Learn how the Use Case Tree Method maps all knowledge, data, and functionality."
+keywords:
+ - knowledge capture
+ - knowledge management
+ - enterprise knowledge
+ - EKG method
+ - enterprise knowledge graph
+ - knowledge mapping
+schema_type: "Article"
---
-# Capture Knowledge
+# D: Capture Knowledge
_Enabling a whole new league of use cases._
diff --git a/docs/objective/composable-business.md b/docs/objective/composable-business.md
index 18cd5808..64635e3e 100644
--- a/docs/objective/composable-business.md
+++ b/docs/objective/composable-business.md
@@ -1,28 +1,145 @@
---
-title: Composable Business
+title: "B: Composable Business"
authors:
- Jacobus Geluk
hide:
- toc
+description: "Making the enterprise adaptive through modular knowledge and reusable capabilities. Learn how the Use Case Tree Method enables composable business architecture."
+keywords:
+ - composable business
+ - business composability
+ - modular architecture
+ - EKG method
+ - enterprise knowledge graph
+ - adaptive enterprise
+schema_type: "Article"
---
-# Composable Business
+# B: Composable Business
-The Future of Business Is Composable
+_Making the enterprise adaptive through modular knowledge and
+reusable capabilities_
+## Objective
-!!! info
+A composable business is one that can adapt and reconfigure itself
+continuously — not through massive reorganisations or costly rewrites,
+but through modular, reusable, and semantically connected components.
- Work in progress. Points to make:
+Composable Business is the organisational expression of the Enterprise
+Knowledge Graph (EKG) and the Use Case Tree (UCT) method. It represents
+the ability to assemble business capabilities dynamically from trusted,
+reusable building blocks: use cases, data products, stories, workflows,
+and ontologies — all governed within the EKG.
- - Explain that the [Use Case Tree (UCT)](../concept/use-case-tree.md) is the ultimate way to implement
- what Gartner now calls "Composable Business":
- - https://www.gartner.com/smarterwithgartner/gartner-keynote-the-future-of-business-is-composable
- - Same for "Packaged Business Capabilities (PBCs)" (also called Packaged Business Components):
- - https://www.elasticpath.com/blog/what-are-packaged-business-capablities
- - https://www.elasticpath.com/blog/what-is-the-difference-between-PBCs-and-microservices
- - https://blog.dreamfactory.com/enterprise-it-building-blocks-the-packaged-business-capability/
- - Explain what's missing with the various proposed approaches in the articles above.
- Why Semantic Technology and in particular EKG & the UCT is key to _really_ make this fly.
+## Why It Matters
+Most organisations struggle to change because their systems, data, and
+processes are tightly coupled and fragmented. Innovation requires
+coordination across dozens of silos, each with its own models and
+assumptions.
+
+Composable Business replaces this fragility with semantic modularity —
+every business capability becomes a governed component that can be
+reused, combined, or replaced without breaking the whole.
+
+The result:
+
+- Faster adaptation to market or regulatory change
+- Continuous innovation without re-engineering core systems
+- Resilience through modular design
+- Clarity and governance through shared semantics
+
+## The Role of the Use Case Tree (UCT)
+
+The Use Case Tree (UCT) is the organising structure of composability.
+It defines how business capabilities are decomposed into modular use
+cases, each of which can be modelled, implemented, and run
+independently, yet still fit coherently into the enterprise
+architecture.
+
+Every node in the UCT represents a reusable component — a semantic
+package containing:
+
+- Defined outcomes and personas
+- Stories (tool functions or APIs)
+- Data products and ontologies
+- Workflows and policies
+
+This makes the UCT the semantic package manager of the EKG — similar to
+how npmjs.org or pypi.org manage software packages — but at enterprise
+scale, spanning business, data, and knowledge assets.
+
+## Composable Business vs. Reuse Enablement
+
+### Two sides of the same semantic coin
+
+While Composable Business and Reuse Enablement both aim to make the
+enterprise modular, they operate at different levels of abstraction.
+The table below outlines how they relate and reinforce one another
+within the EKGF Method.
+
+| Aspect | Composable Business | Reuse Enablement |
+|--------|---------------------|------------------|
+| Focus / Orientation | _How business capabilities are composed, orchestrated, and evolved_ | _How knowledge assets and components are packaged and shared_ |
+| Primary Question | "How do we assemble business capabilities from reusable parts to adapt to change?" | "How do we design those reusable parts so they can be assembled safely and meaningfully?" |
+| Scope | Business and operational level — orchestrating Use Cases, Personas, and Stories into composable outcomes. | Technical and semantic level — creating and governing reusable artifacts: ontologies, datasets, shapes, workflows, data products, and Stories. |
+| Key Mechanism | **Use Case Tree (UCT)** as the orchestration layer: composing and aligning modular business capabilities. | **Use Case Tree (UCT)** as the packaging layer: publishing reusable components and metadata to the Enterprise Knowledge Graph (EKG) for discovery and re-use. |
+| Relationship to the EKG | The EKG provides the shared semantics and service interfaces that make cross-use-case orchestration possible. | The EKG provides the shared identifiers, ontologies, and provenance that make reuse safe and traceable. |
+| Value Proposition | Agility and adaptability: the ability to reconfigure the enterprise dynamically in response to change. | Efficiency and consistency: the ability to reduce duplication and accelerate delivery through reusable, versioned components. |
+| Primary Users | Business and solution architects; transformation leads. | Data and knowledge engineers; ontology and platform teams. |
+| Outcome | Composable business capabilities and adaptive workflows. | Reusable semantic components and data products. |
+| Relationship to Each Other | Composable business **depends** on reuse. Without reusable components, there is nothing to compose. | Reuse **finds purpose** in composability. Without higher-level composition, reuse is just technical hygiene. |
+
+!!! tip "Two sides of the same semantic coin"
+
+ **Reuse Enablement** creates the *building blocks*.
+
+ **Composable Business** assembles them into *living systems*.
+
+ Every successful technology ecosystem has a way to share reusable
+ components — the JavaScript world has [*npm*](https://www.npmjs.com)
+ with over 3.5 million packages, the Python world has
+ [*PyPI*](https://pypi.org) with over 600,000 packages, and so on — each
+ enabling developers to build upon a vast ecosystem of reusable
+ components.
+
+ The **Use Case Tree (UCT)** plays the same role for the **Enterprise
+ Knowledge Graph (EKG)**: it is the semantic package manager that makes
+ every business capability, data product, and workflow discoverable,
+ versioned, and ready to be reused and composed safely across the
+ enterprise.
+
+
+
+## Getting Started
+
+To move toward a composable business:
+
+1. Model your business capabilities using the UCT — define outcomes,
+ personas, and dependencies.
+2. Publish reusable components (stories, data products, ontologies) to
+ the EKG with clear provenance and semantics.
+3. Compose new capabilities by linking and orchestrating existing
+ components rather than building from scratch.
+4. Govern the lifecycle of use cases and their subcomponents —
+ versioning, approval, and retirement all managed within the EKG.
+5. Measure reuse and adaptability as key indicators of enterprise
+ maturity.
+
+## Related Objectives
+
+- [Enable Reuse](enable-reuse.md)
+- [Capture Knowledge](capture-knowledge.md)
+- [Manage Modularity](modularity.md)
+- [Achieve Interoperability](interoperability.md)
+
+## Summary
+
+Composable Business is not a new methodology — it is the natural
+outcome of applying the EKGF Method.
+When business capabilities, data products, and knowledge artifacts are
+structured and governed through the EKG and the UCT, the enterprise
+itself becomes composable: a living system of reusable knowledge, ready
+to evolve continuously.
diff --git a/docs/objective/enable-reuse.md b/docs/objective/enable-reuse.md
index 2b25b5ed..dd721098 100644
--- a/docs/objective/enable-reuse.md
+++ b/docs/objective/enable-reuse.md
@@ -1,15 +1,213 @@
---
-title: Enable Reuse
+title: "M: Enable Reuse"
authors:
- Jacobus Geluk
hide:
- toc
+description: "Building the foundation for composable, scalable enterprise knowledge through reuse. Learn how the Use Case Tree Method enables safe reuse of knowledge assets across teams and domains."
+keywords:
+ - reuse
+ - knowledge reuse
+ - reusable components
+ - EKG method
+ - enterprise knowledge graph
+ - composability
+schema_type: "Article"
---
-# Enable Reuse
+# M: Enable Reuse
-_Create an ecosystem of reusable components for the EKG._
+_Building the foundation for composable, scalable enterprise knowledge_
-The [Use Case Tree](../concept/use-case-tree.md) is a foundational mechanism to create an ecosystem of
-reusable components for the EKG.
+## Objective
+
+**Reuse Enablement** is the discipline of designing, packaging, and
+governing every knowledge asset — use case, ontology, data product, or
+workflow — so that it can be safely reused across teams, domains, and
+generations of technology.
+
+It is the foundation of the Enterprise Knowledge Graph (EKG): without
+reuse, there is no composability, no scalability, and no sustainable
+intelligence.
+The EKGF Method defines reuse not as a technical afterthought but as a
+*core architectural principle* — embedded in the way we plan, build,
+and run every enterprise capability.
+
+## Why It Matters
+
+Enterprises waste enormous effort solving the same problems repeatedly —
+integrating the same data, remodelling the same business rules,
+recreating the same workflows.
+
+Most of this duplication stems from one cause: **knowledge is not shared
+as reusable components**.
+
+When knowledge lives in silos — spreadsheets, slide decks, bespoke
+systems — every project begins from zero.
+By contrast, a reuse-enabled organisation captures its work as
+semantically defined, governed components that can be discovered and
+recomposed anywhere across the enterprise.
+
+The result:
+
+- Drastically reduced duplication and cost
+- Higher quality and consistency through shared models
+- Faster delivery and innovation
+- Stronger alignment across business and technology
+
+## Beyond Data: The Real Meaning of Reuse
+
+Most "semantic technology" initiatives of the past two decades have been
+driven from the **data perspective** — led by integration specialists and
+ontology engineers.
+They delivered powerful data harmonisation but rarely transformed how
+the enterprise actually *works*.
+
+That is where the **Enterprise Knowledge Graph (EKG)** and **Use Case
+Tree (UCT)** shift the paradigm.
+They treat **reuse not as a data exercise**, but as the foundation for
+*application composition*.
+In the EKGF Method, reuse is not limited to triples or ontologies — it
+extends to **behaviour**, expressed as *Stories* and *Workflows*.
+
+Just as **object-oriented programming** in the 1980s combined data and
+methods into a reusable "object,"
+the **Use Case Tree (UCT)** combines data, logic, and process into a
+reusable **semantic package**:
+a use case that contains its meaning (ontology), its data products, and
+its behaviour (stories, workflows, outcomes).
+
+This is the crucial difference:
+
+!!! tip "The EKGF Method paradigm shift"
+
+ Instead of describing data that *others must code against*, the EKGF
+ Method captures *the behaviour itself* — executable, governed, and
+ reusable across domains — without necessarily writing code at all.
+
+In this sense, a **Use Case** in the EKG is just as real and reusable as
+a software package in the JavaScript or Python ecosystems.
+Each can be discovered, installed, versioned, extended, and composed —
+but the EKG package operates at the **semantic and business level**,
+spanning data, logic, and meaning.
+
+That's why **reuse** is not a side effect of the EKG.
+It's the *reason the EKG exists.*
+
+### From DIKW to EKGF: Making Knowledge Executable
+
+The well-known **DIKW Model** (Data → Information → Knowledge → Wisdom)
+has guided information management for decades.
+But it assumes that *Wisdom naturally follows from Knowledge* — as if
+understanding automatically produces action.
+In practice, enterprises rarely reach that state because the bridge from
+*knowing* to *doing* is missing.
+
+The **EKGF Method** extends this model by adding the **operational
+dimension**:
+knowledge becomes **behaviour**, behaviour becomes **reusable**, and
+reuse powers **composability**.
+This is the *Path to Executable Knowledge* — where understanding turns
+into governed, shareable, and actionable intelligence.
+
+The diagram below visualises this shift — showing how the EKGF Method
+transforms the classic DIKW hierarchy into a living model of executable,
+reusable knowledge.
+
+
+
+Traditional DIKW ends at understanding.
+The EKGF Method continues by modelling behaviour, packaging it as reusable
+use cases, and feeding it back into a composable enterprise — closing the
+loop between data, knowledge, and operational wisdom.
+
+## The Role of the Use Case Tree (UCT)
+
+In the EKGF Method, the **Use Case Tree (UCT)** is the mechanism that
+makes reuse practical and governed.
+
+Each node in the UCT acts as a *semantic package* — a defined,
+versioned, and discoverable unit of business capability.
+Within a UCT package, teams can register:
+
+- **Ontologies and shapes** defining meaning and validation
+- **Stories** (tool functions or APIs) that implement reusable logic
+- **Data products** describing and delivering reusable datasets
+- **Workflows and policies** orchestrating repeatable patterns
+
+Every successful technology ecosystem has a way to **share reusable
+components** — the JavaScript world has [*npm*](https://www.npmjs.com)
+with over 3.5 million packages, the Python world has
+[*PyPI*](https://pypi.org) with over 600,000 packages, and so on — each
+enabling developers to build upon a vast ecosystem of reusable
+components.
+The **Use Case Tree (UCT)** plays the same role for the **Enterprise
+Knowledge Graph (EKG)**: it is the *semantic package manager* that makes
+every business capability, dataset, and workflow discoverable, versioned,
+and ready for reuse across the organisation.
+
+## Reuse Enablement vs. Composable Business
+
+### Two sides of the same semantic coin
+
+While *Reuse Enablement* and *Composable Business* share the same
+foundation, they operate at different levels of abstraction.
+The table below summarises their relationship within the EKGF Method.
+
+| Aspect | Composable Business | Reuse Enablement |
+|--------|---------------------|------------------|
+| Focus / Orientation | _How business capabilities are composed, orchestrated, and evolved_ | _How knowledge assets and components are packaged and shared_ |
+| Primary Question | "How do we assemble business capabilities from reusable parts to adapt to change?" | "How do we design those reusable parts so they can be assembled safely and meaningfully?" |
+| Scope | Business and operational level — orchestrating Use Cases, Personas, and Stories into composable outcomes. | Technical and semantic level — creating and governing reusable artifacts: ontologies, datasets, shapes, workflows, data products, and Stories. |
+| Key Mechanism | **Use Case Tree (UCT)** as _the orchestration layer_: composing and aligning modular business capabilities. | **Use Case Tree (UCT)** as _the packaging layer_: publishing reusable components and metadata to the Enterprise Knowledge Graph (EKG) for discovery and re-use. |
+| Relationship to the EKG | The EKG provides the shared semantics and service interfaces that make cross-use-case orchestration possible. | The EKG provides the shared identifiers, ontologies, and provenance that make reuse safe and traceable. |
+| Value Proposition | Agility and adaptability: the ability to reconfigure the enterprise dynamically in response to change. | Efficiency and consistency: the ability to reduce duplication and accelerate delivery through reusable, versioned components. |
+| Primary Users | Business and solution architects; transformation leads. | Data and knowledge engineers; ontology and platform teams. |
+| Outcome | Composable business capabilities and adaptive workflows. | Reusable semantic components and data products. |
+| Relationship to Each Other | Composable business **depends on** reuse. Without reusable components, there is nothing to compose. | Reuse **finds purpose** in composability. Without higher-level composition, reuse is just technical hygiene. |
+
+!!! tip "Two sides of the same semantic coin"
+
+ **Reuse Enablement** creates the *building blocks*.
+
+ **Composable Business** assembles them into *living systems*.
+
+ Both rely on the **Use Case Tree (UCT)** as the semantic package
+ manager of the Enterprise Knowledge Graph — governing how business,
+ data, and technical artifacts are versioned, discoverable, and
+ composable.
+
+## How to Enable Reuse in Practice
+
+1. **Model once, reuse everywhere:** design ontologies, shapes, and
+ stories as modular assets stored and versioned in the EKG.
+
+2. **Publish via the UCT:** register components as packages with clear
+ ownership, metadata, and dependency relationships.
+
+3. **Govern for trust:** validate with SHACL, record provenance, enforce
+ entitlements and lifecycle policies.
+
+4. **Discover and compose:** make all reusable artifacts searchable and
+ connectable across domains and teams.
+
+5. **Measure reuse:** track adoption, version dependencies, and impact
+ metrics to sustain continuous improvement.
+
+## Related Objectives
+
+- [Composable Business](composable-business.md)
+- [Manage Modularity](modularity.md)
+- [Achieve Interoperability](interoperability.md)
+- [Capture Knowledge](capture-knowledge.md)
+
+## Summary
+
+Reuse Enablement is how the EKG turns knowledge into infrastructure.
+By packaging every use case, ontology, and data product as a governed,
+discoverable component within the Use Case Tree, the enterprise builds a
+foundation for **scalable intelligence and composable business**.
+
+When reuse becomes second nature, innovation stops reinventing the wheel
+— and starts accelerating on shared semantic ground.
diff --git a/docs/objective/increase-quality.md b/docs/objective/increase-quality.md
index a71d1d4f..a39a54c6 100644
--- a/docs/objective/increase-quality.md
+++ b/docs/objective/increase-quality.md
@@ -1,11 +1,20 @@
---
-title: Increase Quality
+title: "I: Increase Quality"
authors:
- Jacobus Geluk
hide:
- toc
+description: "Enforce 100% test coverage based on real business scenarios and requirements. Learn how the Use Case Tree Method ensures quality through comprehensive testing."
+keywords:
+ - quality assurance
+ - test coverage
+ - business scenarios
+ - EKG method
+ - enterprise knowledge graph
+ - testing methodology
+schema_type: "Article"
---
-# Increase Quality
+# I: Increase Quality
_Enforce 100% test coverage based on real business scenarios and requirements._
diff --git a/docs/objective/index.md b/docs/objective/index.md
index 38fa28d0..d6d1e9c3 100644
--- a/docs/objective/index.md
+++ b/docs/objective/index.md
@@ -1,3 +1,14 @@
+---
+description: "Discover the primary objectives for creating a Use Case Tree in the Use Case Tree Method. Learn how interoperability, composability, reuse, and other objectives drive enterprise knowledge graph success."
+keywords:
+ - EKG objectives
+ - use case tree objectives
+ - enterprise knowledge graph goals
+ - EKG method
+ - business objectives
+schema_type: "WebPage"
+---
+
# Objectives
The primary reasons for creating a [Use Case Tree](../concept/use-case-tree.md) are:
@@ -8,79 +19,79 @@ The primary reasons for creating a [Use Case Tree](../concept/use-case-tree.md)
-- :material-cached:{ .lg } __Interoperability Achieved__
+- __Interoperability Achieved__
{% include-markdown "objective/interoperability.md"
start="" end="" %}
[:octicons-arrow-right-24: Learn more](interoperability.md)
-- :material-cached:{ .lg } __Business Composability Improved__
+- __Business Composability Improved__
{% include-markdown "objective/composable-business.md"
start="" end="" %}
[:octicons-arrow-right-24: Learn more](composable-business.md)
-- :material-cached:{ .lg } __Requirements Captured__
+- __Requirements Captured__
{% include-markdown "objective/know-what-the-business-wants.md"
start="" end="" %}
[:octicons-arrow-right-24: Learn more](know-what-the-business-wants.md)
-- :material-cached:{ .lg } __Knowledge Captured__
+- __Knowledge Captured__
{% include-markdown "objective/capture-knowledge.md"
start="" end="" %}
[:octicons-arrow-right-24: Learn more](capture-knowledge.md)
-- :material-cached:{ .lg } __Gaps Bridged__
+- __Gaps Bridged__
{% include-markdown "objective/bridge-the-gap.md"
start="" end="" %}
[:octicons-arrow-right-24: Learn more](bridge-the-gap.md)
-- :material-cached:{ .lg } __Expectations Managed__
+- __Expectations Managed__
{% include-markdown "objective/manage-expectations.md"
start="" end="" %}
[:octicons-arrow-right-24: Learn more](manage-expectations.md)
-- :material-cached:{ .lg } __Did not boil the ocean__
+- __Did not boil the ocean__
{% include-markdown "objective/avoid-boiling-the-ocean.md"
start="" end="" %}
[:octicons-arrow-right-24: Learn more](avoid-boiling-the-ocean.md)
-- :material-cached:{ .lg } __Disruption Avoided__
+- __Disruption Avoided__
{% include-markdown "objective/avoid-disruption.md"
start="" end="" %}
[:octicons-arrow-right-24: Learn more](avoid-disruption.md)
-- :material-cached:{ .lg } __Quality Increased__
+- __Quality Increased__
{% include-markdown "objective/increase-quality.md"
start="" end="" %}
[:octicons-arrow-right-24: Learn more](increase-quality.md)
-- :material-cached:{ .lg } __Aligned with Strategy__
+- __Aligned with Strategy__
{% include-markdown "objective/align-with-business-strategy.md"
start="" end="" %}
[:octicons-arrow-right-24: Learn more](align-with-business-strategy.md)
-- :material-cached:{ .lg } __Delivered__
+- __Delivered__
{% include-markdown "objective/strategic-usecases.md"
start="" end="" %}
[:octicons-arrow-right-24: Learn more](strategic-usecases.md)
-- :material-cached:{ .lg } __Modularity Managed__
+- __Modularity Managed__
{% include-markdown "objective/modularity.md"
start="" end="" %}
[:octicons-arrow-right-24: Learn more](modularity.md)
-- :material-cached:{ .lg } __Reuse Enabled__
+- __Reuse Enabled__
{% include-markdown "objective/enable-reuse.md"
start="" end="" %}
diff --git a/docs/objective/interoperability.md b/docs/objective/interoperability.md
index 9b36e08c..ec87ec92 100644
--- a/docs/objective/interoperability.md
+++ b/docs/objective/interoperability.md
@@ -1,13 +1,22 @@
---
-title: Interoperability
+title: "A: Interoperability"
summary: Interoperability Achieved
authors:
- Carlos Tubbax
date: 2022-06-23
some_url: https://method.ekgf.org/objective/interoperability/
+description: "Enable interoperability across the enterprise at high levels of maturity. Learn how the Use Case Tree Method achieves enterprise-wide data and system interoperability through semantic standards."
+keywords:
+ - interoperability
+ - enterprise interoperability
+ - data interoperability
+ - EKG method
+ - enterprise knowledge graph
+ - semantic interoperability
+schema_type: "Article"
---
-# Interoperability Achieved
+# A: Interoperability Achieved
_Enable interoperability across the enterprise at high levels of maturity._
diff --git a/docs/objective/know-what-the-business-wants.md b/docs/objective/know-what-the-business-wants.md
index e695d459..57267526 100644
--- a/docs/objective/know-what-the-business-wants.md
+++ b/docs/objective/know-what-the-business-wants.md
@@ -1,11 +1,20 @@
---
-title: Know what the business wants & why
+title: "C: Know what the business wants & why"
authors:
- Jacobus Geluk
hide:
- toc
+description: "Know exactly what the business—the customer or product owner—really needs, short-, mid- and long-term. Learn how the Use Case Tree Method captures true business requirements."
+keywords:
+ - business requirements
+ - requirements capture
+ - business needs
+ - EKG method
+ - enterprise knowledge graph
+ - product owner
+schema_type: "Article"
---
-# Know what the business wants & why
+# C: Know what the business wants & why
_Know exactly what the business---the customer or
diff --git a/docs/objective/manage-expectations.md b/docs/objective/manage-expectations.md
index 567144f3..79ac4634 100644
--- a/docs/objective/manage-expectations.md
+++ b/docs/objective/manage-expectations.md
@@ -1,11 +1,20 @@
---
-title: Best form of ”expectation management”
+title: "F: Best form of \"expectation management\""
authors:
- Jacobus Geluk
hide:
- toc
+description: "Create an agreed and realistic strategic roadmap aligned to business strategy. Learn how the Use Case Tree Method manages expectations across complex enterprises."
+keywords:
+ - expectation management
+ - strategic roadmap
+ - business strategy
+ - EKG method
+ - enterprise knowledge graph
+ - roadmap planning
+schema_type: "Article"
---
-# Best form of ”expectation management”
+# F: Best form of "expectation management"
_Create an agreed and realistic strategic roadmap aligned to business strategy._
diff --git a/docs/objective/modularity.md b/docs/objective/modularity.md
index ba4b9dc8..3a739a93 100644
--- a/docs/objective/modularity.md
+++ b/docs/objective/modularity.md
@@ -1,15 +1,24 @@
---
-title: Modularity
+title: "L: Modularity"
summary: Introducing EKG modularity
authors:
- Carlos Tubbax
date: 2022-05-01
some_url: https://method.ekgf.org/objective/modularity/
hide:
- - toc
+- toc
+description: "Build with modular, reusable components instead of monolithic systems. Learn how the Use Case Tree Method enables modular architecture for enterprise systems."
+keywords:
+ - modularity
+ - modular architecture
+ - reusable components
+ - EKG method
+ - enterprise knowledge graph
+ - system design
+schema_type: "Article"
---
-# Modularity
+# L: Modularity
_Build with modular, reusable components instead of monolithic systems._
diff --git a/docs/objective/strategic-usecases.md b/docs/objective/strategic-usecases.md
index fa7b5e7b..70899beb 100644
--- a/docs/objective/strategic-usecases.md
+++ b/docs/objective/strategic-usecases.md
@@ -1,12 +1,21 @@
---
-title: The ability to deliver strategic use cases
+title: "K: The ability to deliver strategic use cases"
authors:
- Jacobus Geluk
hide:
- toc
+description: "Deliver strategic use cases that cannot realistically be done with other technologies. Learn how the Use Case Tree Method enables unique business capabilities."
+keywords:
+ - strategic use cases
+ - unique capabilities
+ - EKG advantages
+ - EKG method
+ - enterprise knowledge graph
+ - competitive advantage
+schema_type: "Article"
---
-# The ability to deliver strategic use cases
+# K: The ability to deliver strategic use cases
_Deliver strategic use cases that cannot realistically be done with other technologies._
diff --git a/docs/other/faq.md b/docs/other/faq.md
index d2cdb9a5..d8a20f3f 100644
--- a/docs/other/faq.md
+++ b/docs/other/faq.md
@@ -2,7 +2,16 @@
title: FAQ
author:
- Jacobus Geluk
----
+description: "Frequently asked questions about the Use Case Tree Method and Use Case Tree. Get answers about use cases, stories, personas, data products, and the Enterprise Knowledge Graph methodology."
+keywords:
+ - FAQ
+ - frequently asked questions
+ - EKG method FAQ
+ - use case tree FAQ
+ - enterprise knowledge graph questions
+schema_type: "FAQPage"
+---
+
# Frequently Asked Questions
## What is a Use Case?
@@ -18,12 +27,12 @@ datasets (or data products), ontologies, workflows, user interface models and fu
A user story can be seen as a black-box function with inputs and outputs.
We model these inputs and outputs initially just as simple "[Concepts](../concept/concept.md)"
(and the terms that are being used for those concepts).
-By adding more and more detail to these stories, they eventually become runnable or
-executable and can be invoked as an HTTP API, in response to a Kafka message,
+By adding more and more detail to these stories, they eventually become runnable or
+executable and can be invoked as an HTTP API, in response to a Kafka message,
or via any other technology.
-Stories can be "implemented" using SPARQL, SQL, Gremlin, or calls to external APIs
-of any sort since they're seen as a "black box," it really doesn't matter, although usually,
-the easiest way to implement them is, of course, SPARQL since an EKG is primarily an
+Stories can be "implemented" using SPARQL, SQL, Gremlin, or calls to external APIs
+of any sort since they're seen as a "black box," it really doesn't matter, although usually,
+the easiest way to implement them is, of course, SPARQL since an EKG is primarily an
RDF-based world.
A story is (by precedent) linked to only one use case.
@@ -45,19 +54,19 @@ the term [Use Case Tree](../concept/use-case-tree.md/).
## Are use case trees actually trees (hierarchies)?
-No, they are [DAGs](https://en.wikipedia.org/wiki/Directed_acyclic_graph) (one use case
-can support, and be supported by, many others) but we obviously didn't want to call it
+No, they are [DAGs](https://en.wikipedia.org/wiki/Directed_acyclic_graph) (one use case
+can support, and be supported by, many others) but we obviously didn't want to call it
"Use Case DAG" :-)
## What is the detail needed behind each use case? - Narrative? Happy case? Exceptions
-Here's a [template](../concept/use-case.md#__tabbed_1_5) for the kind of information that we need
+Here's a [template](../concept/use-case.md#plan-build-run) for the kind of information that we need
to collect for any given use case during the various phases in their life cycle.
## How are use cases named?
- traditionally: verb phrase including noun, e.g., _Maintain customer accounts_
-- actual: noun phrase for a data subject area, which may be singular or plural,
+- actual: noun phrase for a data subject area, which may be singular or plural,
for instance, _Customer Accounts_.
With just using nouns, any given use case tree starts to look like one of three things
@@ -69,7 +78,7 @@ or some sort of combination of it, especially at the higher levels in the tree:
This may be a bit confusing because it's none of those three things, but there is a close relationship
between these four concepts (domains, capabilities, organizational units, and Use Case Trees).
-And that's precisely how it should be; your EKG's modular structure should look like
+And that's precisely how it should be; your EKG's modular structure should look like
_your_ enterprise structure.
However:
@@ -124,11 +133,11 @@ life cycle, from initiation to production and beyond.
Changing terms simply because some external ontology has a "better" name for the same concept is
not helping.
-The whole point of using semantic technology is that we can easily model all "semantic conundrums"
+The whole point of using semantic technology is that we can easily model all "semantic conundrums"
and make sure that we always address "the business" (i.e., the customer) with their language
while keeping the backend EKG models "generic" and linked to any number of appropriate ontologies.
-A "concept" in the EKG/Method is, therefore, "the linking pin," linking local business language to
+A "concept" in the Use Case Tree Method is, therefore, "the linking pin," linking local business language to
any other appropriate concepts in any number of other ontologies.
- ` usesConcept .`
@@ -137,7 +146,7 @@ any other appropriate concepts in any number of other ontologies.
- ` datatype .` (optional)
- ` ....` (all kinds of mapping information)
- ` term ` (where term can be a multilingual context-specific name for the concept or
- a technology-stack specific name)
+ a technology-stack specific name)
- ` isInputFor `
- ` isOutputFor `
- ` isUsedInUseCase ` (derived from the stories of the use case)
@@ -165,7 +174,7 @@ of this method, spanning across the workflows of many use cases.
The Use Case Tree of an organization has everything to do with Strategy;
overall [Business Strategy](https://maturity.ekgf.org/pillar/business/capability-area/strategy-actuation/),
-[Data Strategy](https://maturity.ekgf.org/pillar/data/capability-area/data-strategy/),
+[Data Strategy](https://maturity.ekgf.org/pillar/data/capability-area/data-strategy/),
[Organizational Strategy](https://maturity.ekgf.org/pillar/organization/capability-area/executive-leadership/capability/organizational-strategy/)
and [Technology Strategy](https://maturity.ekgf.org/pillar/technology/capability-area/technology-strategy/).
@@ -208,12 +217,12 @@ just stand for some external "legacy" system. For instance if your organization
an old mainframe running "Billing" for 40 years, built with COBOL, then we can add
that as a Use Case, a black box really, to the Use Case Tree.
-The implementation of a use case can be anything. Implementation details will be
+The implementation of a use case can be anything. Implementation details will be
added by engineers using their own models.
Point is: everyone can talk to the Use Case Tree; business people, any stakeholder,
end users, ontologists, data modelers, knowledge graph engineers or other data scientists,
-COBOL programmers, devops people, they're all talking about the same deliverables that
+COBOL programmers, devops people, they're all talking about the same deliverables that
the business ultimately pays for.
## How, if at all, is a UCT specific to Knowledge Graphs?
@@ -236,22 +245,22 @@ Selecting the "right" first use cases is a bit of an art.
Some rules of thumb:
- Define use cases with a minimum number of "dependencies"
- - dependencies come in many forms, ontologies, datasets, people, maturity requirements,
- departments and so forth.
+ - dependencies come in many forms, ontologies, datasets, people, maturity requirements,
+ departments and so forth.
- Start with "reference data" (so that we have something to link to)
- Build upon standard use cases (downloadable from EKGF and others, or other internal departments)
- Select the shortest path in the tree
- - should lead quickly to the delivery of a "lighthouse use case" or a "strategic use case",
- delivering real value to the business, ideally value that no other technology stack can currently
- (realistically) provide.
+ - should lead quickly to the delivery of a "lighthouse use case" or a "strategic use case",
+ delivering real value to the business, ideally value that no other technology stack can currently
+ (realistically) provide.
- Deliver straight to production, from the first tiny use case onwards
- - Implement full test-driven development with 100% test-coverage
- - Implement full end-to-end [continuous deployment](https://en.wikipedia.org/wiki/Continuous_deployment)
- or [GitOps](https://www.gitops.tech/).
- - Get through all red-tape and learning curve with the technology first so that delivery
- of all subsequent use cases is not held back and it can be proven that price and time-to-market
- will be reduced drastically with each subsequent use case delivery.
-
+ - Implement full test-driven development with 100% test-coverage
+ - Implement full end-to-end [continuous deployment](https://en.wikipedia.org/wiki/Continuous_deployment)
+ or [GitOps](https://www.gitops.tech/).
+ - Get through all red-tape and learning curve with the technology first so that delivery
+ of all subsequent use cases is not held back and it can be proven that price and time-to-market
+ will be reduced drastically with each subsequent use case delivery.
+
## What is reusable?
Most Use Cases can be developed as "reusable components" (if you do it right).
@@ -272,14 +281,14 @@ competitors.
Every successful technology stack has a central place where the community publishes their
reusable components, for JavaScript that is [https://npmjs.org](https://npmjs.org), for
Java we have [Maven Central](https://mvnrepository.com/repos/central) (and others), Python has
-[https://pypi.org](https://pypi.org) and for the EKG we have the EKGF Catalog
-(under development, it's in its very early stages still) at
+[https://pypi.org](https://pypi.org) and for the EKG we have the EKGF Catalog
+(under development, it's in its very early stages still) at
[https://catalog.ekgf.org](https://catalog.ekgf.org).
## How are Use Cases "plug and play?"
Any given use case can be "enriched" with more and more detail during its development.
-This eventually leads to it becoming "executable", which in effect turns it into the
+This eventually leads to it becoming "executable", which in effect turns it into the
EKG equivalent of an "application".
Use Cases at this level of sophistication are then "plug and play" and can be re-deployed
in other EKGs.
@@ -351,11 +360,11 @@ corporate styling etc.
## How can you drive (data) modeling?
One major "lesson learned" is that semantic technology and knowledge graphs easily
-allow people to "[boil the ocean](../objective/avoid-boiling-the-ocean.md)" and
-"model the whole world" using generic abstract ontologies, sometimes even up to
+allow people to "[boil the ocean](../objective/avoid-boiling-the-ocean.md)" and
+"model the whole world" using generic abstract ontologies, sometimes even up to
philosophical levels of abstraction.
-One of the key objectives of the EKG/Method is to [avoid boiling the ocean](../objective/avoid-boiling-the-ocean.md)
+One of the key objectives of the Use Case Tree Method is to [avoid boiling the ocean](../objective/avoid-boiling-the-ocean.md)
by creating a laser sharp description of what the business needs and pays for.
And make that description testable and therefore verifiable.
@@ -373,7 +382,7 @@ can be built as an EKG use case.
Practically, there will always be many other systems that are specialised in what they're
doing. Source of record systems, PeopleSoft, Salesforce, spreadsheets, trading systems,
-blockchains and the like. The EKG can serve as a layer on top of all those other systems,
+blockchains and the like. The EKG can serve as a layer on top of all those other systems,
connecting the dots across the enterprise or ecosystem.
## Not suitable for?
@@ -383,4 +392,3 @@ semantic graph database products (aka "triple stores") are the de-facto choice t
the EKG. However, many other technologies can be used as well, with a bit more work,
such as time series databases, Kafka, relational databases and labeled property graph (LPG)
databases.
-
diff --git a/docs/other/index.md b/docs/other/index.md
index 8925ec70..2e046bb2 100644
--- a/docs/other/index.md
+++ b/docs/other/index.md
@@ -1,11 +1,22 @@
+---
+description: "Explore other Object Management Group (OMG) Enterprise Knowledge Graph Forum initiatives including EKG Principles, Maturity Model, Catalog, and related resources."
+keywords:
+ - EKGF
+ - object management group
+ - enterprise knowledge graph forum
+ - EKG resources
+ - EKG principles
+ - EKG maturity model
+schema_type: "WebPage"
+---
+
# Other
-The Enterprise Knowledge Graph Foundation is working on multiple initiatives that
-have lead to various websites:
+The Object Management Group (OMG) Enterprise Knowledge Graph Forum (EKGF) is a managed community within OMG and is working on multiple initiatives that have lead to various websites:
## ekgf.org
-The main website of the Foundation: [https://ekgf.org](https://ekgf.org)
+The main website of the OMG-managed forum: [https://ekgf.org](https://ekgf.org)
## Principles
diff --git a/docs/other/seo-guide.md b/docs/other/seo-guide.md
new file mode 100644
index 00000000..f2c63ddf
--- /dev/null
+++ b/docs/other/seo-guide.md
@@ -0,0 +1,192 @@
+# SEO Guide for Content Authors
+
+This guide explains how to optimize your content for search engines when writing documentation for the Use Case Tree Method site.
+
+## Page-Specific Meta Descriptions
+
+Every page should have a unique, descriptive meta description. Add it in the frontmatter at the top of your Markdown file:
+
+```yaml
+---
+description: "A clear, concise description of what this page covers (150-160 characters recommended)"
+keywords:
+ - keyword1
+ - keyword2
+ - keyword3
+schema_type: "Article" # or "WebPage", "HowTo", etc.
+---
+```
+
+### Best Practices for Descriptions
+
+- **Length**: Aim for 150-160 characters (Google typically shows up to 160)
+- **Be specific**: Describe what the reader will learn, not generic marketing copy
+- **Include keywords**: Naturally incorporate relevant search terms
+- **Action-oriented**: Use active voice when possible
+- **Unique**: Each page must have a different description
+
+### Example
+
+```yaml
+---
+description: "Learn how outcomes define the business value and success criteria for use cases in the Use Case Tree Method. Outcomes provide the 'why' behind every requirement."
+keywords:
+ - outcome
+ - business outcome
+ - use case outcome
+ - EKG method
+schema_type: "Article"
+---
+```
+
+## Keywords
+
+Add relevant keywords as a list in the frontmatter. These help search engines understand your content:
+
+```yaml
+keywords:
+ - primary keyword
+ - secondary keyword
+ - related term
+```
+
+### Keyword Best Practices
+
+- **3-5 keywords**: Don't overdo it
+- **Relevant**: Only include terms actually discussed on the page
+- **Natural**: Use terms your audience would search for
+- **Specific**: Prefer specific terms over generic ones
+
+## Schema.org Structured Data
+
+The `schema_type` field determines the type of structured data (JSON-LD) added to the page:
+
+- **`Article`**: For documentation pages, tutorials, guides
+- **`WebPage`**: For general pages
+- **`HowTo`**: For step-by-step instructions
+- **`FAQPage`**: For FAQ pages
+
+## Page Titles
+
+Page titles are automatically generated from your H1 heading. Best practices:
+
+- **Clear and descriptive**: The H1 should clearly state what the page is about
+- **Include keywords**: Naturally incorporate important search terms
+- **Unique**: Each page should have a distinct title
+- **Concise**: Keep it under 60 characters when possible
+
+## Content Optimization
+
+### Headings Structure
+
+Use proper heading hierarchy:
+
+```markdown
+# H1 - Page Title (only one per page)
+## H2 - Main Sections
+### H3 - Subsections
+```
+
+### Internal Linking
+
+Link to related pages within the documentation:
+
+```markdown
+Learn more about [Use Cases](use-case.md) and [Outcomes](outcome.md).
+```
+
+### Images
+
+- Use descriptive alt text for all images
+- Include relevant keywords in filenames when appropriate
+- Optimize image file sizes for faster loading
+
+### Summary Sections
+
+The `` and `` comments create summary sections that can be used for SEO. Make sure summaries are:
+
+- Clear and concise
+- Include key concepts
+- Naturally incorporate keywords
+
+## Social Media Optimization
+
+Open Graph and Twitter Card tags are automatically generated from your page metadata. To customize:
+
+### Custom Images
+
+Add a custom image for social sharing:
+
+```yaml
+---
+description: "..."
+image: "/assets/images/custom-page-image.png"
+---
+```
+
+### Custom Titles
+
+The page title is used for social sharing. Make sure it's compelling and descriptive.
+
+## Technical SEO
+
+The following are handled automatically:
+
+- ✅ Canonical URLs
+- ✅ Sitemap generation
+- ✅ Mobile-responsive design
+- ✅ Fast page loading
+- ✅ Structured data (JSON-LD)
+- ✅ Open Graph tags
+- ✅ Twitter Card tags
+- ✅ robots.txt (located at `/docs/robots.txt` and copied to site root during build)
+
+## Checklist for New Pages
+
+When creating a new page, ensure you have:
+
+- [ ] Unique meta description (150-160 chars)
+- [ ] Relevant keywords (3-5 terms)
+- [ ] Appropriate schema_type
+- [ ] Clear, descriptive H1 title
+- [ ] Proper heading hierarchy
+- [ ] Internal links to related pages
+- [ ] Alt text for images
+- [ ] Summary section (if applicable)
+
+## Examples
+
+### Concept Page
+
+```yaml
+---
+description: "Learn how [concept] works in the Use Case Tree Method. [Specific benefit or learning outcome]."
+keywords:
+ - concept-name
+ - related-term
+ - EKG method
+schema_type: "Article"
+---
+# Concept Name
+```
+
+### Process Page
+
+```yaml
+---
+description: "Step-by-step guide to [process name] in the Use Case Tree Method. Learn how to [specific action]."
+keywords:
+ - process-name
+ - workflow
+ - EKG method
+schema_type: "HowTo"
+---
+# Process Name
+```
+
+## Questions?
+
+If you have questions about SEO optimization, please refer to:
+- [Google's SEO Starter Guide](https://developers.google.com/search/docs/fundamentals/seo-starter-guide)
+- [Schema.org Documentation](https://schema.org/)
+
diff --git a/docs/process/build/allocate.md b/docs/process/build/allocate.md
index d9103794..909f7e0e 100644
--- a/docs/process/build/allocate.md
+++ b/docs/process/build/allocate.md
@@ -3,6 +3,15 @@ authors:
- Jacobus Geluk
hide:
- toc
+description: "Allocate resources, organize a team, and start creating a Center of Excellence for the EKG. Learn how to structure development workstreams for the EKG Platform and use cases."
+keywords:
+ - allocate
+ - resource allocation
+ - EKG team
+ - center of excellence
+ - EKG method
+ - enterprise knowledge graph team
+schema_type: "HowTo"
---
# Allocate
diff --git a/docs/process/build/deliver.md b/docs/process/build/deliver.md
index da57c422..42ebd27a 100644
--- a/docs/process/build/deliver.md
+++ b/docs/process/build/deliver.md
@@ -3,6 +3,15 @@ authors:
- Jacobus Geluk
hide:
- toc
+description: "Continuously improve and deliver small increments frequently. Learn how to deploy use cases to production and establish a delivery cadence in the Deliver phase."
+keywords:
+ - deliver
+ - continuous delivery
+ - incremental delivery
+ - EKG deployment
+ - EKG method
+ - enterprise knowledge graph delivery
+schema_type: "HowTo"
---
# Deliver
diff --git a/docs/process/build/design.md b/docs/process/build/design.md
index d3749778..6a19a683 100644
--- a/docs/process/build/design.md
+++ b/docs/process/build/design.md
@@ -3,6 +3,15 @@ authors:
- Jacobus Geluk
hide:
- toc
+description: "Design the EKG Platform architecture and use case specifications. Learn how to architect both the technical platform and business-focused use case designs in the Design phase."
+keywords:
+ - design
+ - EKG architecture
+ - platform design
+ - use case design
+ - EKG method
+ - enterprise knowledge graph architecture
+schema_type: "HowTo"
---
# Design
diff --git a/docs/process/build/implement.md b/docs/process/build/implement.md
index cbbe0b17..fcba4589 100644
--- a/docs/process/build/implement.md
+++ b/docs/process/build/implement.md
@@ -3,6 +3,15 @@ authors:
- Jacobus Geluk
hide:
- toc
+description: "Detail the use case by implementing executable models. Learn how to transform requirements into semantic models that run on the EKG Platform in the Implement phase."
+keywords:
+ - implement
+ - use case implementation
+ - executable models
+ - semantic models
+ - EKG method
+ - enterprise knowledge graph implementation
+schema_type: "HowTo"
---
# Implement
diff --git a/docs/process/build/index.md b/docs/process/build/index.md
index f2e80fd8..482a68fe 100644
--- a/docs/process/build/index.md
+++ b/docs/process/build/index.md
@@ -3,6 +3,15 @@ authors:
- Jacobus Geluk
hide:
- toc
+description: "Building an EKG-based use case involves detailed requirements gathering structured around the Use Case Tree, all the way to delivery. Learn the Build phase: Allocate, Design, Implement, Test, Verify, and Deliver."
+keywords:
+ - EKG build
+ - build phase
+ - executable models
+ - no-code EKG
+ - EKG method
+ - enterprise knowledge graph development
+schema_type: "HowTo"
---
# Build
diff --git a/docs/process/build/test.md b/docs/process/build/test.md
index d0f1a11d..030e9b47 100644
--- a/docs/process/build/test.md
+++ b/docs/process/build/test.md
@@ -3,6 +3,15 @@ authors:
- Jacobus Geluk
hide:
- toc
+description: "Add test scenarios and deliver full coverage based on real business scenarios. Learn how to ensure quality through comprehensive testing in the Use Case Tree Method Test phase."
+keywords:
+ - test
+ - EKG testing
+ - test coverage
+ - business scenario testing
+ - EKG method
+ - enterprise knowledge graph testing
+schema_type: "HowTo"
---
# Test
diff --git a/docs/process/build/verify.md b/docs/process/build/verify.md
index 89cf61eb..c795a979 100644
--- a/docs/process/build/verify.md
+++ b/docs/process/build/verify.md
@@ -3,6 +3,15 @@ authors:
- Jacobus Geluk
hide:
- toc
+description: "Verify the use case implementation with the business stakeholders. Learn how to validate that delivered functionality meets business requirements and outcomes."
+keywords:
+ - verify
+ - business verification
+ - stakeholder validation
+ - requirements verification
+ - EKG method
+ - enterprise knowledge graph verification
+schema_type: "HowTo"
---
# Verify
diff --git a/docs/process/index.md b/docs/process/index.md
index 1bd99a6c..3fc80a28 100644
--- a/docs/process/index.md
+++ b/docs/process/index.md
@@ -2,80 +2,86 @@
hide:
- toc
- navigation
+description: "The Use Case Tree Method process: Plan (strategy & scope), Build (executable models), and Run (operate & optimize). Learn the three-phase approach to developing Enterprise Knowledge Graphs."
+keywords:
+ - EKG process
+ - EKG methodology
+ - plan build run
+ - EKG method
+ - enterprise knowledge graph
+ - development process
+schema_type: "WebPage"
---
# Process
=== "Steps"
-
- Think big, start small, rinse, repeat, accelerate.
+ Strategic vision, stakeholder alignment, and the [Use Case Tree](../concept/use-case-tree.md).
+ Essential at the start, repeatable at any level---even for individual use cases.
-----
- [Envision](./plan/envision.md),
- [Discover](./plan/discover.md),
- [Assess](./plan/assess.md),
- [Train](./plan/train.md) and
- [Chart](./plan/chart.md).
+ - [Envision](./plan/envision.md)
+ - [Discover](./plan/discover.md)
+ - [Assess](./plan/assess.md)
+ - [Train](./plan/train.md)
+ - [Chart](./plan/chart.md)
[:octicons-arrow-right-24: Learn more](./plan/index.md)
- - :construction_site:{ .lg } __[Build](build/index.md)__
-
- -----
-
- "Building" an EKG-based use case involves
- everything from detailed requirements gathering---structured
- around the [Use Case Tree](../concept/use-case-tree.md)---all the way up to delivery of
- components for your production EKG-platform.
-
- [:octicons-arrow-right-24: Learn more](./build/index.md)
-
- - :material-run:{ .lg } __[Run](run/index.md)__
-
- ---
+ -
- Deploying, Operating, Measuring and Optimizing an
- [EKG/Platform](../vocab/ekg-platform.md) that
- serves many Use Cases across the Enterprise.
-
- [:octicons-arrow-right-24: Learn more](./run/index.md)
-
- - :material-foot-print: Steps
-
- -----
-
- [Envision](./plan/envision.md),
- [Discover](./plan/discover.md),
- [Assess](./plan/assess.md),
- [Train](./plan/train.md) and
- [Chart](./plan/chart.md).
-
- - :material-foot-print: Steps
+ Capture [Stories](../concept/story.md), [Workflows](../concept/workflow.md), and [Concepts](../concept/concept.md).
+ Specify executable behavior as semantic models---mostly no-code---for reusable components.
-----
- [Allocate](./build/allocate.md),
- [Design](./build/design.md),
- [Implement](./build/implement.md),
- [Test](./build/test.md),
- [Verify](./build/verify.md) and
- [Deliver](./build/deliver.md).
+ - [Allocate](./build/allocate.md)
+ - [Design](./build/design.md)
+ - [Implement](./build/implement.md)
+ - [Test](./build/test.md)
+ - [Verify](./build/verify.md)
+ - [Deliver](./build/deliver.md)
- - :material-foot-print: Steps
+ [:octicons-arrow-right-24: Learn more](./build/index.md)
+
+ -
+ :material-rocket-launch:{ .lg }
+
+ __[Run](run/index.md)__
+ Operate & Optimize
+
+
+
+ Deploy, operate, and optimize the [EKG/Platform](../vocab/ekg-platform.md).
+ Measure [Outcomes](../concept/outcome.md), monitor [Workflows](../concept/workflow.md),
+ serve multiple use cases across the enterprise.
-----
- [Deploy](./run/deploy.md),
- [Operate](./run/operate.md),
- [Measure](./run/measure.md) and
- [Optimize](./run/optimize.md).
+ - [Deploy](./run/deploy.md)
+ - [Operate](./run/operate.md)
+ - [Measure](./run/measure.md)
+ - [Optimize](./run/optimize.md)
+ [:octicons-arrow-right-24: Learn more](./run/index.md)
+
=== "Diagram"
diff --git a/docs/process/plan/assess.md b/docs/process/plan/assess.md
index 5ecee88a..af0a69e6 100644
--- a/docs/process/plan/assess.md
+++ b/docs/process/plan/assess.md
@@ -3,14 +3,25 @@ authors:
- Jacobus Geluk
hide:
- toc
+description: "Assess your organization's maturity in non-functional requirements using the EKG Maturity Model. Learn how to evaluate readiness and bridge gaps before implementing use cases."
+keywords:
+ - assess
+ - maturity assessment
+ - EKG maturity model
+ - organizational readiness
+ - EKG method
+ - enterprise knowledge graph assessment
+schema_type: "HowTo"
---
# Assess
-_Assess where your current organization stands in terms of the non-functional requirements and
-where it should be to be able to support the use cases as they come out of the [Discover phase](discover.md).
-These assessments are based on the [Maturity Model for the EKG (EKG/Maturity)](https://maturity.ekgf.org).
-This is partly about "the how" and "can we?"._
+
+- current state
+- required next state
+- maturity (buss/org/data/tech)
+- scalability assessment
+
Perform an assessment of the current and desired state of maturity of the organization
diff --git a/docs/process/plan/chart.md b/docs/process/plan/chart.md
index 464a9efd..52208861 100644
--- a/docs/process/plan/chart.md
+++ b/docs/process/plan/chart.md
@@ -3,13 +3,25 @@ authors:
- Jacobus Geluk
hide:
- toc
+description: "Craft a proper business case, manage expectations, and define what success means. Learn how to chart a solid plan with stakeholder support and clear success criteria in the Chart phase."
+keywords:
+ - chart
+ - business case
+ - EKG planning
+ - success criteria
+ - EKG method
+ - enterprise knowledge graph planning
+schema_type: "HowTo"
---
# Chart
-_Craft a proper "business case", manage expectations, define crystal clear what success
-means and what is needed to get there.
-This is about "when are we done?"._
+
+- viable roadmap
+- business case
+- stakeholder agreement
+- mandate
+
Build a business case that charts out a solid plan, well-supported by all
diff --git a/docs/process/plan/discover.md b/docs/process/plan/discover.md
index af2515d8..073c640d 100644
--- a/docs/process/plan/discover.md
+++ b/docs/process/plan/discover.md
@@ -3,28 +3,40 @@ authors:
- Jacobus Geluk
hide:
- toc
+description: "Discover all use cases in the given scope and create a Use Case Tree that shows a viable pathway towards strategic goals. Learn how to identify business outcomes and select the shortest path to value in the Discover phase."
+keywords:
+ - discover
+ - use case discovery
+ - use case tree creation
+ - EKG method
+ - enterprise knowledge graph
+ - business outcomes
+schema_type: "HowTo"
---
# Discover
-_Discover all use cases in the given scope, short-term and long-term,
-create a “[Use Case Tree](../../concept/use-case-tree.md)” that shows a viable, realistic, logical,
-and successful pathway towards strategic goals.
-This is about “the what” and how it relates to "the why"._
+
+- strategic [use cases](../../concept/use-case.md) & desired [business outcomes](../../concept/outcome.md)
+- initial [Use Case Tree](../../concept/use-case-tree.md) and primary branch
+- shared business language & knowledge
+- aligned priorities and reuse opportunities
+
-Discover all strategic use cases in the given scope that support the agreed vision
-and strategy. Create the initial UCT for the organization. Identify desired mid and long term
-business outcomes. Select the primary branch in the use case tree to focus on, break that part
-of the use case tree down into deeper levels, identify the shortest pathway to real business
+Discover all strategic [use cases](../../concept/use-case.md) in the given scope that support the agreed vision
+and strategy. Create the initial [Use Case Tree (UCT)](../../concept/use-case-tree.md) for the organization.
+Identify desired mid and long term [business outcomes](../../concept/outcome.md).
+Select the primary branch in the Use Case Tree to focus on, break that part
+of the Use Case Tree down into deeper levels, identify the shortest pathway to real business
value.
The Discover phase translates organizational and business priorities into
strategic use cases.
-We convert your priorities into data requirements devoid of any technical considerations.
+In this step, priorities are converted into data requirements devoid of any technical considerations.
The output aligns all stakeholders on intermediate deliverables and emphasizes those with
the greatest reuse potential.
-This helps you refine your business case and plan your implementation as a series of
+This helps refine the business case and plan implementation as a series of
steppingstones toward more strategic goals.
## Approach
@@ -32,7 +44,7 @@ steppingstones toward more strategic goals.
The team works with business experts and change managers in a series of interactive
workshops to define requirements.
The team adopts the business language in the selected context to capture goals,
-data requirements, data stories and process/work flows.
+data requirements, [stories](../../concept/story.md) and [workflows](../../concept/workflow.md).
These are aligned as a set of visual roadmaps to be used to create onward business
cases.
The team leverages the [knowledge graph maturity model](../../vocab/maturity-model.md)
@@ -45,14 +57,14 @@ to help frame each deliverable in terms of staged business capabilities.
## Outputs
-All outputs below describe the properties of what a Use Case Tree is:
+All outputs below describe the properties of what a [Use Case Tree](../../concept/use-case-tree.md) is:
-* Identification of strategic use cases, priorities and desired business outcomes
-* Initial scope in the form of one priority strategic use case,
- one branch of the Use Case Tree to focus on
+* Identification of strategic [use cases](../../concept/use-case.md), priorities and desired [business outcomes](../../concept/outcome.md)
+* Initial scope in the form of one priority strategic [use case](../../concept/use-case.md),
+ one branch of the [Use Case Tree](../../concept/use-case-tree.md) to focus on
* Evaluation criteria from both a business process and data perspective to ensure
EKG synchronization with defined requirements
-* Conversion of strategic priorities into a staged “use case tree” specifying
+* Conversion of strategic priorities into a staged [Use Case Tree](../../concept/use-case-tree.md) specifying
business functionality and data requirements
* A shared understanding of the requirements for success including the investments
needed to deliver against expected functionality
@@ -61,8 +73,8 @@ All outputs below describe the properties of what a Use Case Tree is:
* One-to-one and end-to-end linkage between a plain english business user story and the
evidence that this user story has been delivered, works and stays working[^testing]
* **A permanent artifact, a shared model, continuously being improved, that all stakeholders across
- the enterprise can talk to for the whole life-cycle of any given use case (even in production)**
-* Living data structure that becomes part of the EKG itself for its whole life-cycle
+ the enterprise can talk to for the whole life-cycle of any given [use case](../../concept/use-case.md) (even in production)**
+* Living data structure that becomes part of the [Enterprise Knowledge Graph](../../vocab/ekg.md) itself for its whole life-cycle
* Modular structure of components that allows for an ecosystem of internal and external reusable
components compliant with standards set by the EKGF.
@@ -74,8 +86,19 @@ and exactly trace cost, risk, timelines etc.
### The Use Case Tree practice
-Explanation of the key principles of how your EKG and its development can be structured and what
-leads to successful and modular implementations.
+Explanation of the key principles of how an EKG and its development can be structured in an organization
+and what leads to successful and modular implementations.
+
+### What is a "strategic use case"
+
+A **strategic use case** is more than just a good first candidate to implement.
+It is a lighthouse use case that is of **strategic importance to the business**:
+it visibly saves money, increases profit, improves quality, reduces risk, or boosts efficiency
+in a way that matters at the C‑level.
+
+Strategic use cases are the scenarios that convince executive leadership to **invest in EKG strategically**,
+not just as a one‑off project.
+They demonstrate that an EKG‑based approach can unlock long‑term competitive advantage, not merely solve a local problem.
### Examples of Strategic Use Cases
@@ -90,18 +113,41 @@ and Customer 360.
* Improving Data Quality generally. Risk
* Supporting the digitalization / Transform / Innovation agenda, capability play
-### Identity your Strategic Use Cases & Business Outcomes
+### Identify your Strategic Use Cases & Business Outcomes
-Identify your own corporate “strategic use cases” and formulate their expected business outcomes.
+Identify the organization's own “strategic use cases” and formulate their expected business outcomes.
Think outside the box, “dream a little”, think long term, set long term goals so that a reuse strategy
-can be derived. Rough sketch of areas where the organization could (and should) possibly go if
-innovations, technology & org could deliver.
+can be derived. Rough sketch areas where the organization could (and should) possibly go if
+innovations, technology and organization could deliver.
### Select a Strategic Use Case & Identify Stakeholders
-After step 3 we can select one area to dive into, with the agreement of all key stakeholders for that
+After step 3, select one area to dive into, with the agreement of all key stakeholders for that
area.
+### What is "the right use case" (to start with)
+
+One of the key outcomes of the Discover phase is the identification and definition of the **first** [use case](../../concept/use-case.md) to start with.
+Ideally, this is a **lighthouse use case**: a concrete example that shows everyone why building use cases in an Enterprise Knowledge Graph context is worth the effort in the first place.
+
+Expectations around this first use case are often sky-high — it can become a go/no‑go decision point for further EKG investment — so **expectation management is critical**.
+Stakeholders need to understand that the first use case may actually take **longer** to implement than building something similar on the existing "bread and butter" technology stack:
+teams know those tools, they have done it many times before, and can “crank out” another solution quickly.
+Doing the same thing with a **new technology stack** and several **new paradigms** (graph, semantics, EKG, GenAI, etc.) almost always takes more time at first.
+The real payoff is that **every subsequent use case will go faster and faster**, because:
+
+- you are building everything with **reuse** in mind (components, models, workflows, test assets)
+- you rapidly build up a catalog of reusable EKG components
+- GenAI can increasingly help you discover, combine, and implement those components faster
+
+When choosing the lighthouse use case:
+
+- pick a use case that is **not “typical”** — something that is genuinely **hard to do with existing technology**, for example because it combines complex data from multiple sources or domains
+- pick a use case that sits **in the middle of the designated scope**, with **high reuse potential** into neighboring areas of the [Use Case Tree](../../concept/use-case-tree.md)
+
+The goal is not to “win” on raw delivery speed for the first use case, but to **prove the point**:
+that an EKG‑based, reuse‑driven approach will make each subsequent use case cheaper, faster, and more robust than the last.
+
### Deep-dive Strategic Use Case & Business Outcomes
Develop the details of the “use case tree” of the selected top-level strategic use case.
@@ -113,9 +159,3 @@ delivered in a logical sequence.
All stakeholders have realistic expectations and know exactly what is going to be delivered,
why, and in which order.
-## TODO
-
-* What is "the right use case" (to start with)
-* What is a "strategic use case"
-
-
diff --git a/docs/process/plan/ekg-method.code-workspace b/docs/process/plan/ekg-method.code-workspace
new file mode 100644
index 00000000..b8045b8f
--- /dev/null
+++ b/docs/process/plan/ekg-method.code-workspace
@@ -0,0 +1,34 @@
+{
+ "folders": [
+ {
+ "path": "../../.."
+ },
+ {
+ "path": "../../../../ekg-catalog"
+ },
+ {
+ "path": "../../../../ekg-maturity"
+ },
+ {
+ "path": "../../../../ekg-principles"
+ },
+ {
+ "path": "../../../../ekglib"
+ },
+ {
+ "path": "../../../../benchmark"
+ },
+ {
+ "path": "../../../../agnos-website"
+ }
+ ],
+ "settings": {
+ "yaml.schemas": {
+ "https://squidfunk.github.io/mkdocs-material/schema.json": "mkdocs.yml"
+ },
+ "yaml.customTags": [
+ "tag:yaml.org,2002:python/name",
+ "tag:yaml.org,2002:python/object/apply"
+ ]
+ }
+}
diff --git a/docs/process/plan/envision.md b/docs/process/plan/envision.md
index 302d0486..a539bc0c 100644
--- a/docs/process/plan/envision.md
+++ b/docs/process/plan/envision.md
@@ -3,18 +3,44 @@ authors:
- Jacobus Geluk
hide:
- toc
+description: "Create a vision for the EKG that is shared by all key-stakeholders. Learn how to establish a long-term integrated business, data, and technology strategy in the Envision phase of the Use Case Tree Method."
+keywords:
+ - envision
+ - EKG vision
+ - strategic planning
+ - EKG method
+ - enterprise knowledge graph strategy
+ - stakeholder alignment
+schema_type: "HowTo"
---
# Envision
-_Create a vision for the EKG that is shared by all key-stakeholders._
-_This is about “the why” long term._
+
+- shared EKG vision
+- why EKG is critical for long-term business health
+- shared strategy to realize that vision
+
-Create a shared vision, where do we think that our organization should be,
-three to ten years down the road and how do we leverage our unique data and knowledge to become,
+Create a shared vision: where do we think that our organization should be
+three to ten years down the road, and how do we leverage our unique data and knowledge to become,
or stay, a leader in our markets? Translate this to a (long term) integrated business, data
-and technology strategy, identify primary stakeholders and initial scope.
+and technology strategy, and identify primary stakeholders and an agreed scope.
+
+That scope can range from an enterprise-wide transformation, to a single business unit or region,
+down to one critical use case or system that needs to be replaced or improved. There is no golden rule.
+In this phase it is important to **think big first** and allow everyone to "dream a little"—some
+“pie in the sky thinking” should be tolerated to explore what *could* be possible, before converging
+on a pragmatic initial scope and direction that everyone can commit to.
+
+At the same time, generative AI has become a board-level priority: organizations that fail to learn
+how to safely and effectively leverage GenAI risk becoming irrelevant. A virtual Enterprise Knowledge Graph
+is a critical enabler here. Without an EKG as a trusted semantic layer, GenAI agents are forced to interact
+directly with a patchwork of legacy systems, APIs, and data sources of unknown quality—often a recipe for
+fragile, unexplainable behaviour. With an EKG in place, GenAI agents can work against a coherent,
+well-governed, business-aligned knowledge layer, dramatically improving reliability, explainability,
+and long-term agility.
Clarify the potential of knowledge graph for your enterprise and help position it
as part of your overall data and technology strategy.
diff --git a/docs/process/plan/index.md b/docs/process/plan/index.md
index 08774d09..3ec7ab77 100644
--- a/docs/process/plan/index.md
+++ b/docs/process/plan/index.md
@@ -8,71 +8,91 @@ some_url: https://method.ekgf.org/process/plan/
hide:
- toc
- navigation
+description: "Think big, start small, rinse, repeat, accelerate. Learn the Plan phase of the Use Case Tree Method: Envision, Discover, Assess, Train, and Chart your Enterprise Knowledge Graph strategy."
+keywords:
+ - EKG planning
+ - plan phase
+ - EKG strategy
+ - use case tree planning
+ - EKG method
+ - enterprise knowledge graph planning
+schema_type: "HowTo"
---
# Plan
-=== "Intro"
+
+**_Think big, start small, rinse, repeat, accelerate._**
+
- **
- _Think big, start small, rinse, repeat, accelerate._
- **
-
- [//]: # (??? note "Rationale")
-
- In most large organizations, there are many ways to justify a migration to a more data-centric and less
- siloed operation. There are countless use cases where a more data-centric and “holistic” approach could
- be extremely beneficial. Starting with EKG requires planning and preparation. Think big, start small.
- Start with the right use case, the right business case, the right team, prepare for success.
- Establishing an EKG can be seen as a journey, it’s generally not something that can be done in “three
- months”, even though---with the right amount of planning and preparation---the first use case that can
- be delivered can be done in such a short time-frame, it should fit in a larger vision and strategy. Proper
- expectation management is key.
-
- Since EKG brings in many new “paradigms”, it is crucial to have proper expectation management in place,
- all relevant stakeholders in the given scope need to understand what it is that you’re trying to achieve,
- what the longer-term vision behind it is, agree on that vision, whereby the first use cases need to be
- very convincing and need to be delivered successfully.
-
- That's what this method is for. See also all other [objectives](../../objective/index.md).
+[//]: # (??? note "Rationale")
-=== "Steps"
+In most large organizations, there are many ways to justify a migration to a more data-centric and less
+siloed operation. There are countless use cases where a more data-centric and "holistic" approach could
+be extremely beneficial. Starting with EKG requires planning and preparation. Think big, start small.
+Start with the right use case, the right business case, the right team, prepare for success.
+Establishing an EKG can be seen as a journey, it's generally not something that can be done in "three
+months", even though---with the right amount of planning and preparation---the first use case that can
+be delivered can be done in such a short time-frame, it should fit in a larger vision and strategy. Proper
+expectation management is key.
-
-
- - :material-cached:{ .lg } __[Envision](envision.md)__
-
- {% include-markdown "process/plan/envision.md"
- start="" end="" %}
- [:octicons-arrow-right-24: Learn more](envision.md)
-
- - :material-cached:{ .lg } __[Discover](discover.md)__
-
- {% include-markdown "process/plan/discover.md"
- start="" end="" %}
- [:octicons-arrow-right-24: Learn more](discover.md)
-
- - :material-cached:{ .lg } __[Assess](assess.md)__
-
- {% include-markdown "process/plan/assess.md"
- start="" end="" %}
- [:octicons-arrow-right-24: Learn more](assess.md)
-
- - :material-cached:{ .lg } __[Train](train.md)__
-
- {% include-markdown "process/plan/train.md"
- start="" end="" %}
- [:octicons-arrow-right-24: Learn more](train.md)
-
- - :material-cached:{ .lg } __[Chart](chart.md)__
-
- {% include-markdown "process/plan/chart.md"
- start="" end="" %}
- [:octicons-arrow-right-24: Learn more](chart.md)
+Since EKG brings in many new "paradigms", it is crucial to have proper expectation management in place,
+all relevant stakeholders in the given scope need to understand what it is that you're trying to achieve,
+what the longer-term vision behind it is, agree on that vision, whereby the first use cases need to be
+very convincing and need to be delivered successfully.
+
+That's what this method is for. See also all other [objectives](../../objective/index.md).
+
+## Steps
+
+
+
+- :material-cached:{ .lg } __[Envision](envision.md)__
+
+ - shared EKG vision
+ - why EKG is critical for long-term business health
+ - shared strategy to realize that vision
+
+ [:octicons-arrow-right-24: Learn more](envision.md)
+
+- :material-cached:{ .lg } __[Discover](discover.md)__
+
+ - strategic use cases
+ - initial use case tree
+ - business knowledge
+ - priorities & outcomes
+
+ [:octicons-arrow-right-24: Learn more](discover.md)
+
+- :material-cached:{ .lg } __[Assess](assess.md)__
+
+ - current state
+ - required next state
+ - maturity (buss/org/data/tech)
+ - scalability assessment
+
+ [:octicons-arrow-right-24: Learn more](assess.md)
+
+- :material-cached:{ .lg } __[Train](train.md)__
+
+ Get everyone involved up to speed with all the fundamentals around EKG,
+ the various new paradigms and especially how EKG requires a number of
+ new ways of looking at various topics.
-