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.

The thesis

A system's capability is determined by the knowledge operations it performs reliably — not by the format of the data it retrieves.

What the framework proposes

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.

The capability profile

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.

1

Retrieval control

Can it reliably find the right evidence?

2

Context modeling

Does it preserve structure, hierarchy, provenance?

3

Synthesis

Can it combine evidence across sources and surface contradictions?

4

Computation

Can it produce exact, verifiable answers?

5

Relational reasoning

Can it traverse entities, dependencies, multi-hop links?

6

Orchestration

Can it plan, route, recover, coordinate tools?

7

Governance

Are permissions, provenance, and auditability enforced on every operation?

8

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.

The floor

"Fit to task" still has teeth

A capability profile is insufficient — and the framework will say so — when any of three conditions hold.

1

A required operation is missing

The task demands an operation the system cannot perform reliably.

2

Governance is below the risk class

An irreversible-action workflow without human-approval gates is unsafe, no matter how well it reasons.

3

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

The floor

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.

Where this meets Opero

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.

About the research

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.

Picture of Gerasimos Xydas

Gerasimos Xydas

Chief Product & Innovation Officer, Superbo

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.