Stop asking what your AI system stores. Start asking what it can do
Knowledge Operations is a published capability model for Knowledge-Augmented Systems (KAS) — a framework for classifying AI systems by the knowledge operations they perform reliably, not the data formats they use. Developed by Gerasimos Xydas, Chief Product & Innovation Officer at Superbo.
Published May 2026
DOI-registered
CC BY 4.0 open license
"We do RAG" tells you nothing
Two AI systems can both be called "RAG" while performing fundamentally different kinds of knowledge work. Two systems can use completely different substrates — vectors, SQL, graphs, agents — while satisfying the exact same requirement.
Yet the market still ranks systems by architecture: vector database → knowledge graph → agents, as if every organization must climb the same ladder. The result is predictable. Teams buy "agentic reasoning" when their actual failure was permission propagation. Procurement selects one platform for workloads that demand opposite capabilities. Gartner forecasts that more than 40% of agentic AI projects will be canceled by 2027 — and capability mismatch is a recurring contributor. Architecture labels are a poor guide to capability. This framework proposes the inverse.
A system's capability is determined by the knowledge operations it performs reliably — not by the format of the data it retrieves.
Knowledge-Augmented Systems, profiled — not ranked.
The whitepaper defines Knowledge-Augmented Systems (KAS): AI systems that combine language models with external knowledge, structure, computation, and execution. RAG is one access pattern within KAS — not a synonym for it. Capability is then measured across the operations a workload actually demands.
K0-K6
Capability Archetypes
Seven operation classes — retrieve, scope, interpret, combine, compute, traverse, orchestrate. Archetypes, not maturity levels: workloads select the subset they need. Nobody has to “graduate” to graphs or agents.
G0-G6
Governance Scale
From no controls to runtime monitoring with human-approval gates. Each capability class carries a minimum governance floor — and regulated industries should treat G4 as baseline.
EVAL
Evaluation as first-class
A capable system knows when to answer and when to abstain. Calibrated uncertainty, abstention behavior, and per-class evaluation artifacts are part of the model — not an afterthought.
Together they produce a capability profile — a shape across eight dimensions, not a score on a ladder. Different workloads produce different shapes. That difference is the whole point.
Eight questions every knowledge system must answer
Profile a workload across all eight. Different demands draw a different shape — and the shape, not a rank, tells you what the system can actually do.
Retrieval control
Can it reliably find the right evidence?
Context modeling
Does it preserve structure, hierarchy, provenance?
Synthesis
Can it combine evidence across sources and surface contradictions?
Computation
Can it produce exact, verifiable answers?
Relational reasoning
Can it traverse entities, dependencies, multi-hop links?
Orchestration
Can it plan, route, recover, coordinate tools?
Governance
Are permissions, provenance, and auditability enforced on every operation?
Evaluation
Does it know when to answer and when to stay silent?
A knowledge graph does not make a system more capable than one using vector search. Ten agents are not more capable than one. The right architecture matches the epistemic demands of the task.
"Fit to task" still has teeth
A capability profile is insufficient — and the framework will say so — when any of three conditions hold.
A required operation is missing
The task demands an operation the system cannot perform reliably.
Governance is below the risk class
An irreversible-action workflow without human-approval gates is unsafe, no matter how well it reasons.
The operation set is disproportionate.
A system that over-engineers — paying latency, cost, and complexity the task cannot absorb — is not "more capable." It's a worse fit.
That last one matters most. In this framework, over-capability is a defect, not a flex
Built for the people who have to choose
Enterprise buyers
Evaluating AI vendors who all claim "agentic RAG" — the framework includes a vendor evaluation checklist designed to surface real capability, not rehearsed demos.
Architects
Designing knowledge systems who need to justify why this workload needs synthesis but not graph traversal — with a capability-profile template to run per workload.
Practitioners
Working on retrieval, agentic systems, and evaluation — the paper is openly licensed (CC BY 4.0) and versioned for community refinement.
We publish the model. We also build to it.
Frameworks are easy to publish and hard to live by. The KAS model is the lens Superbo applies to its own platform: every Opero deployment starts from the workload's capability profile — which knowledge operations it demands, which governance floor its risk class requires, which evaluation artifacts prove it works on the client's own corpus. That's why our GTM motion is discovery-led: we profile the workload before we propose the architecture. Not because it sounds good, but because the alternative — selling the same stack to every workload — is the failure mode this research names.
Independent research, sponsored by Superbo.
Knowledge Operations: A Capability Model for AI Systems was developed by Gerasimos Xydas, Chief Product & Innovation Officer at Superbo, and is sponsored by Superbo as part of our commitment to advancing the discipline of enterprise agentic AI.
The framework is published as an open, DOI-registered whitepaper under a CC BY 4.0 license — free to use, cite, and build upon. It is offered as a thinking framework for the industry, not a vendor scorecard.
KAS.
What you need to know.
Frequently asked questions
An AI system that combines language models with external knowledge, structure, computation, and execution to answer questions, support decisions, or perform workflows grounded in authoritative information. KAS is the umbrella category; RAG is just one access pattern within it.
The market ranks AI systems by architecture — vector DB, knowledge graph, agents — which tells buyers almost nothing about real capability. Two systems can both be called 'RAG' while doing fundamentally different work, and capability mismatch is a recurring contributor to failed agentic AI projects.
RAG describes one pattern: retrieve, inject, generate. KAS describes the whole class of systems that may use RAG, NL-to-SQL, graph traversal, tool orchestration, or any combination — with the architecture determined by the workload, not by the pattern.
A system-level action that transforms, constrains, validates, computes over, or acts upon external knowledge: retrieving, scoping, interpreting, combining, computing, traversing, orchestrating, governing, evaluating. Operations define capability; storage and architecture are just inputs.
The shape a system makes across eight dimensions — retrieval, context, synthesis, computation, relational reasoning, orchestration, governance, and evaluation — rather than a single score or level. Different workloads legitimately produce different shapes, and the difference is the point.
Governance in KAS is measured with a parallel G0-G5 scale measuring governance depth: G0 (no citations or controls), G1 (basic citations), G2 (permission-aware retrieval), G3 (provenance, freshness, calibrated uncertainty), G4 (policy enforcement with redaction and audit logs), G5 (runtime monitoring with human-approval gates).
To procure per workload instead of per industry or vendor narrative: profile the operations the task demands, the governance floor its risk class requires, and the operational budgets (latency, cost, reliability) it must meet. The paper includes a vendor evaluation checklist designed to surface real capability.
Buying one platform to serve workloads with opposite profiles — e.g. K1+K4 analytics and K1+K3+K5+K6 investigation — which over-pays for one and under-serves the other. Both pass surface-level vendor demos; the fix is per-workload procurement.
Yes — it is published as a versioned, DOI-registered whitepaper under a CC BY 4.0 license, free to use, cite, and build upon.
Every Opero engagement starts from the workload's capability profile: which knowledge operations it demands, which governance floor its risk class requires, and which evaluation artifacts prove it works on the client's own corpus.
Profile your workload
Read the framework, then put it to work. In a discovery session, we’ll build a capability profile for one of your real workloads — the operations it demands, the governance floor it requires, and the gap between where you are and where the task needs you to be.