What capabilities, sub-capabilities, architectural patterns, and maturity…

Research Question

What are the key capabilities, sub-capabilities, architectural patterns, and maturity dimensions for tool-using, semi-autonomous Semantic Knowledge Management (SKM) systems that integrate automated harvesting and extraction, Resource Description Framework (RDF) and Web Ontology Language (OWL) based knowledge graphs, dynamic context selection and durable memory references, agent reasoning and orchestration, and semantic interoperability?

Findings

Executive Summary

Tool-using, semi-autonomous Semantic Knowledge Management (SKM) systems require six separable capability domains, and this six-domain structure is best read as an extension of the earlier repository five-pillar model, because it splits knowledge foundations into acquisition versus semantic operations and promotes interoperability and discovery to an explicit control surface.

The recurring architecture is a layered stack in which harvested or virtualized sources feed an RDF and OWL semantic layer queried through SPARQL, while an orchestrator manages dynamic capability discovery, checkpointed state, memory recall, and tool invocation through open protocols such as MCP.

Practical maturity increases when teams move from manual and static practices to versioned semantic models, persistent and interruptible runtime state, governed discovery, and quantitative improvement loops adapted from Capability Maturity Model Integration (CMMI) staging.

The evidence base is strongest for semantic, orchestration, and governance capabilities, and weaker for publicly accessible classical Knowledge Management (KM) taxonomies, so the resulting hierarchy is best treated as a medium-confidence synthesis rather than a settled industry standard.

Key Findings

1. The minimum complete SKM model needs six top-level capability domains, and this is a bounded extension of the earlier five-pillar repository model, because acquisition versus semantic operations and interoperability versus orchestration expose materially different control surfaces, failure modes, and ownership boundaries.
2. Semantic-layer maturity depends on explicit RDF datasets, OWL ontologies, SPARQL query surfaces, collaborative semantic modeling, and query-time reasoning or validation, because these capabilities recur across standards and enterprise semantic platforms and collectively define the semantic control surface of an SKM system.
3. Harvesting and extraction capability must cover both document-derived graph construction and live source virtualization, because GraphRAG-style pipelines and Stardog-style virtual graphs solve complementary parts of the knowledge acquisition problem.
4. Dynamic context and memory capability is best modeled through just-in-time retrieval, thread-scoped short-term state, namespace-scoped long-term memory, checkpointed replay, and resumable interrupts, because those primitives together cover the runtime state-management problems described in current context-engineering and orchestration documentation.
5. Reasoning and orchestration maturity is marked by progression from fixed workflows to planner or supervisor coordination with worker specialization, because public agent guidance and reference architectures repeatedly separate routing, decomposition, supervision, and recovery concerns.
6. Interoperability should be treated as a first-class capability domain, because usable SKM systems need both semantic standards for data and discovery standards for tools, with MCP exposing discoverable tools, resources, and prompts through explicit list and get methods.
7. The minimum operating model requires domain owners, ontology and knowledge engineers, orchestration and platform engineers, governance and evaluation owners, and formal improvement roles, because semantic modeling, runtime control, and maturity assurance are documented as different human workstreams.
8. A practical maturity rubric for SKM systems runs from Initial through Repeatable, Managed, Quantitatively Managed, and Optimizing, with the transitions driven by versioned semantics, persistent runtime state, governed discovery, and measurable control loops rather than by model size alone.

Assumptions

• Assumption: Public product and framework documentation is adequate for capability taxonomy even when it does not provide comparative benchmark data. Justification: This item asks what capabilities and patterns exist, not which vendor performs best.
• Assumption: Translating the requested "repeatable" maturity label to the project-level control stage represented by CMMI's managed practices is acceptable for this item. Justification: The operational difference that matters here is project-local repeatability versus organization-wide governed practice.

Analysis

The cleanest architecture boundary is to treat the semantic layer as the authoritative structure for meaning and traceability, while the orchestration layer owns routing, planning, state persistence, and tool invocation.

This boundary explains why SKM systems need both ontology-native capabilities and agent-runtime capabilities, because semantic correctness does not automatically provide resumability, approval flows, or fault-tolerant task execution.

The minimum complete hierarchy is therefore: knowledge acquisition and extraction; semantic modeling and graph operations; runtime context and memory; reasoning and orchestration; interoperability and discovery; governance with continuous improvement.

The core sub-capabilities under those domains are source registration, harvesting, parsing, semantic normalization, provenance capture, ontology and taxonomy design, mapping and virtualization, validation and reasoning, query and federation, checkpointed thread state, long-term memory stores, routing, decomposition, worker supervision, registry-mediated discovery, open capability description, approval controls, evaluation, and formal improvement loops.

The adapted maturity rubric is: Initial, static documents and manual graph updates with no durable runtime state; Repeatable, scheduled ingestion and explicit schema or tool catalogs; Managed, organization-wide semantic standards, versioned graph lifecycle, checkpointed orchestration, and role separation; Quantitatively Managed, service levels and metrics for freshness, latency, failure, and evaluation quality; Optimizing, dynamic discovery, automated quality checks, and continuous human-supervised improvement.

Risks, Gaps, and Uncertainties

Public evidence on semantic and runtime capabilities is materially stronger than public evidence on classic KM capability taxonomies, so the semantic and orchestration parts of the model are better supported than the legacy-KM comparison layer.

Vendor platform pages establish feature surfaces but not comparative effectiveness, so choices about which sub-capability bundles matter most in production still require environment-specific validation.

The sources describe checkpointed state, durable identifiers, and retrievable long-term memory primitives, but they do not converge on one canonical term for that bundle, so this item uses plain language rather than claiming a settled industry label.

Open Questions

• Which metrics best measure SKM semantic quality at runtime, beyond generic latency and failure metrics?
• What is the lightest-weight governance pattern that still preserves auditability for low-risk internal SKM agents?
• How should graph-derived summaries be invalidated when source documents change frequently?
• Which benchmark or case-study design would best test whether the six-domain model predicts better production outcomes than a simpler five-pillar variant?

sources

• [ ] American Productivity & Quality Center (APQC) Knowledge Management Framework
• [ ] American Productivity & Quality Center (APQC) Process Frameworks
• [x] CMMI Institute What is Capability Maturity Model Integration (CMMI)?
• [x] Capability Maturity Model Integration (CMMI) Institute Levels of capability and performance
• [x] World Wide Web Consortium (W3C) RDF 1.1 Concepts and Abstract Syntax
• [x] W3C OWL 2 Web Ontology Language Document Overview
• [x] W3C SPARQL Protocol and RDF Query Language (SPARQL) 1.1 Query Language
• [x] Edge et al. (2024) From Local to Global: A GraphRAG approach to query-focused summarization
• [x] Model Context Protocol (MCP) Introduction
• [x] Model Context Protocol (MCP) Architecture overview
• [x] Anthropic Effective context engineering for Artificial Intelligence (AI) agents
• [x] metaphacts Semantic knowledge modeling
• [x] Stardog Virtual Graphs
• [x] Stardog Reasoning and inference
• [x] Freitas et al. (2017) Model-driven engineering of multi-agent systems based on ontologies
• [x] LangGraph Overview
• [x] LangGraph Durable execution
• [x] LangGraph Persistence
• [x] LangChain Memory concepts
• [x] LangGraph Interrupts
• [x] Anthropic Building effective agents
• [x] Microsoft Multi-agent Reference Architecture: Reference Architecture
• [x] Microsoft Multi-agent Reference Architecture: Governance
• [x] Mitchell (2026) Dynamic Resource Discovery architecture pattern and context engineering
• [x] Mitchell (2026) Knowledge Graph in the live execution path of multi-step Large Language Model (LLM) systems
• [x] Mitchell (2026) Knowledge Graph lifecycle management for multi-step software agents
• [x] Mitchell (2026) Ontology landscape for curated lexical and structured enterprise context
• [x] Mitchell (2026) Five-pillar Knowledge Management capability model for tool-using, semi-autonomous Artificial Intelligence systems