Knowledge Operations: A Capability Model for AI Systems

1.1 Reasoning operations and control operations

Not every knowledge operation is a reasoning operation. Synthesis under contradiction, multi-hop traversal under constraint, and evaluator-optimizer judgement are reasoning. Scoping, permission enforcement, and audit logging are control operations: they shape what gets reasoned over and what happens with the result. Both classes count toward capability because a workload's reliability depends on the whole set, but conflating them obscures where to invest. A team that buys "agentic reasoning" capability when the actual failure was permission propagation has misdiagnosed the problem and will not fix it by adding agents.

If you take one thing from this paper: the right architecture for a knowledge-augmented workload is determined by the knowledge operations the task class demands, not by the latest vendor narrative or the most fashionable storage choice. Three different teams in the same organization may need three very different KAS profiles. Treating them as a single "RAG initiative" is a common and costly organizational failure mode in this space.

1.2 How this model was derived

The eight capability dimensions and seven capability archetypes are a practitioner synthesis, not an empirical derivation. Their inputs are: (a) the academic literature on retrieval-augmented generation, agentic systems, and multi-hop reasoning cited throughout this paper; (b) the evaluation criteria used by major analyst frameworks for adjacent categories (Forrester's Cognitive Search Wave, Gartner's Market Guide for Enterprise AI Search, IDC's MarketScape for Knowledge Discovery); (c) the failure-mode taxonomies surfaced in agentic RAG surveys [2] and applied-agent guidance [3]; and (d) recurring patterns observed in enterprise RAG deployments. The model is offered as a thinking framework, not a benchmark, and should be revised as evidence accumulates.

1.3 Contributions

This paper makes four contributions. First, it defines Knowledge-Augmented Systems as a workload-oriented category of AI systems in which external knowledge, computation, or state is load-bearing for the answer. Second, it proposes knowledge operations as the unit of capability analysis, in deliberate contrast to format-anchored or architecture-anchored taxonomies. Third, it introduces seven operation archetypes (K0–K6), a parallel governance scale (G0–G5), and an evaluation discipline that treats abstention and calibrated uncertainty as first-class system properties. Fourth, it provides a workload-level profiling method — including a membership test, a five-orthogonal-layer model, per-class evaluation artifacts, and a threat-model mapping — intended for system design, vendor evaluation, and procurement.

2.1 Capability matters only relative to task fitness

We use two distinct terms throughout this paper. Capability describes what knowledge operations a system can perform reliably (the K-class set, the governance level, the evaluation discipline). Fitness describes whether those capabilities meet a workload's required operations, governance prerequisites, evaluation rigor, and operational constraints (latency, cost, reliability). A system can be highly capable on every dimension and still be unfit for a specific workload: over-engineered, too slow, too expensive, or governed at a level the workload doesn't justify. Conversely, a narrow capability profile can be a perfect fit if it matches what the workload actually demands.

For many workloads, a well-governed system that performs only K1 retrieval and K3 synthesis is a better fit than a fragile K6 workflow that attempts all eight operations badly. The first is narrowly capable but well-fitted; the second is broadly capable but poorly fitted.

2.2 The prescriptive floor

"Fitness to task" is not relativism. The framework retains prescriptive force: a capability profile is insufficient when any of the following hold.

• Missing required operation. The task class demands a knowledge operation the system cannot perform reliably. A compliance task that requires temporal reconciliation, run on a system with no temporal reasoning capability, is undersized regardless of how well it performs its other operations.
• Inadequate governance for risk class. The governance level is below the prerequisite for the task's risk class. An irreversible-action workflow operating without human-approval gates is unsafe regardless of how well it reasons.
• Disproportionate operation set. The system performs knowledge operations the task does not require, at a latency, cost, or complexity the task cannot absorb. A K6 orchestration workflow deployed for a task that needs only K1 scoped retrieval is over-engineered, not "more capable", and on a real-world cost-quality tradeoff it is inferior to the simpler system.

This is what allows the framework to declare specific systems unfit for specific workloads, even when the same architecture would be appropriate elsewhere.

3.1 Working definition

A Knowledge-Augmented System is an AI system that combines language models with external knowledge, structure, computation, and execution in order to answer questions, support decisions, or perform workflows grounded in authoritative information.

A knowledge operation is a system-level action that transforms, constrains, validates, computes over, or acts upon external knowledge in a way that is observable at the workload boundary. To qualify, an operation must be (1) a verb the system performs at its boundary, observable as a typed result; (2) not constitutively tied to a single storage format — the same operation is implementable over vectors, graphs, SQL, APIs, or text, even if a given deployment chooses one; (3) what the system does, not what it stores or how it reaches the source (§6.1 elaborates the layer distinction); (4) falsifiable at the boundary — a §8-style benchmark question and a §8.1-style recommended-failure-behavior row can be written for it; and (5) conceptually non-reducible to a single existing K-class without information loss. The full membership test, including the K6 meta-irreducibility carve-out, is in Appendix A.1. The distinction between operations and the substrates that implement them (vector stores, graphs, SQL engines, agent loops) is the move §1's thesis depends on.

3.2 What KAS is not

KAS is a deliberately bounded category. Two boundary conditions are obvious enough to dispose of in a sentence: a model answering from parametric memory alone is outside KAS (no external knowledge participates), and raw search that returns ranked documents for a human reader is not a KAS by itself (no model-mediated operation transforms, computes over, or acts on the results). Three adjacent labels need more careful distinction:

• Not Compound AI Systems in the broad sense. Compound AI Systems (Zaharia et al. [8]) is a useful umbrella term covering any system composed of multiple AI components, including pure orchestration of LLM calls without external knowledge access. KAS does not propose a new technical primitive: the label is a workload-evaluation lens for the subset of compound AI systems where external knowledge, computation, or state is load-bearing for the answer.
• Not Augmented Language Models. Augmented Language Models (Mialon et al. [9]) and Tool-Augmented LLMs (Toolformer [10] and successors) describe LLMs with reasoning, retrieval, or tool-use capabilities trained or prompted into the model. KAS describes the system around such a model: the typed contracts, governance, evaluation, and consumer-facing operations a workload requires. An Augmented LM is a substrate; a KAS is an architecture.
• Not RAG-only. RAG is one access pattern within KAS, not a synonym for it. A KAS may use RAG, NL→SQL, graph traversal, tool orchestration, or any combination; the architecture is determined by the workload, not by the pattern.

What is new about KAS as a label is that it scopes the category by operation classes (the K-dimensions), governance, evaluation, and consumer (human or agent), instead of by any single access pattern, model architecture, or vendor capability. The framing is the novelty, not any one operation.

3.3 Relationship to existing categories

KAS is a refinement of, not a replacement for, several existing categories. Naming them is necessary because each carries an audience that the KAS framing should connect to rather than ignore.

• "Augmented Intelligence" (IBM, in long-running use) describes the human-AI collaboration mode. KAS describes the system architecture independently of how it is consumed; the two are orthogonal.
• "Cognitive Search" (Forrester, established Wave category since 2017) overlaps most strongly with the K1–K3 portion of this model: retrieval, scoping, structure, and synthesis. Vendor capabilities in the category vary widely. KAS extends the framing to include computation, relational reasoning, orchestration, and explicit governance, and replaces feature-based scoring with knowledge-operation profiling.
• "Agentic RAG" (Singh et al., 2025 [2]) primarily emphasizes orchestration over retrieval workflows and maps most directly to K6, but in practice spans retrieval control, synthesis, tool use, and evaluation depending on implementation. KAS situates these within a broader capability framework that does not assume agents are the destination.
• "Naive / Advanced / Modular RAG" (Gao et al., 2023/2024 [11]) is the most cited maturity taxonomy in the space, and the one this paper most directly disagrees with. Gao et al. stage RAG architectures by pipeline shape: Naive (retrieve-then-generate), Advanced (with pre- and post-retrieval refinement), Modular (with rewriteable components). That staging reproduces the format-anchored mistake §2 names. It tells you what the system is built like, not what knowledge operations it performs. As a consequence, Modular RAG and Agentic RAG become difficult to distinguish under the Gao et al. framing — both involve "modules" — even though Agentic RAG introduces a planner that is a categorically different operation (K6) than parameterized module composition. KAS treats the Gao et al. stages as cells in a wider profile rather than as the profile itself.

The contribution of KAS is not the discovery of any one of these capabilities, but the reframing of capability around knowledge operations (including governance and evaluation as cross-cutting axes) and the multi-dimensional capability profile that follows.

3.4 KAS as agent-native architecture

The operation-over-format reframing aligns naturally with the rise of agents as the primary consumers of enterprise knowledge systems. Format-anchored thinking ("we use a vector DB") describes how a system stores knowledge; operation-anchored thinking describes what an agent can ask the system to do. Traditional search was built around a human user examining ranked results; a KAS is built around an agent consuming typed contracts that expose knowledge operations.

The eight capability dimensions correspond, in practice, to the operation and control-plane needs that arise when agents consume enterprise knowledge systems: retrieval, scoping, interpretation, synthesis, computation, traversal, orchestration, governance, and evaluation. Retrieval, scoping, interpretation, synthesis, computation, traversal, and orchestration are agent-facing primitives, not user-facing features. Governance and evaluation are not primitives an agent invokes directly. They are cross-cutting requirements the system must enforce so that an agent can act responsibly on its outputs.

This connects KAS to the broader Agent Experience (AX) framing: software designed primarily for agent consumption instead of human UI. AX is not yet a settled industry discipline with anchoring citations, but practitioners use it as shorthand for the consumer-facing side of the agentic shift, complementary to the system-side framing this paper proposes. The framework remains useful for human-consumed systems (analyst-facing search, document-QA assistants), but it shows its strongest value where the consumer is an agent: an Evidence Pack returned to an LLM planner, a typed artifact passed to a downstream tool, a calibrated-uncertainty signal an agent uses to decide whether to abstain or escalate.

Where those agents need to discover and invoke each other across vendors, the integration surface is a separate framework. Three open standards are converging on this layer. MCP [12] (Model Context Protocol, Anthropic, 2024) connects LLM applications to external data sources and tools. A2A [13][14] (Agent2Agent Protocol, Google 2025, donated to the Linux Foundation in 2025) handles communication and interoperability between opaque agentic applications. AGNTCY [15][16] (Linux Foundation, 2025) covers discovery, identity, messaging, and the OASF schema [17]. These standards tell one agent how to invoke another. KAS tells you what either agent's knowledge operations actually do. The two layers are orthogonal, and Appendix C maps the OASF vocabulary to the K-classes as a worked example; equivalent mappings for MCP tools and A2A agent-card capabilities are deferred to companion work.

4.1 Operational constraints

The eight dimensions describe what a system can do. Operational constraints govern how it should do it. Three are non-negotiable in production:

• Latency. What response time is acceptable for the workload? Iterative multi-hop retrieval and orchestrated tool calls compound latency; this is not free.
• Cost. Per-query LLM and infrastructure cost scales with orchestration depth, context size, and retrieval breadth. Higher capability levels are not inherently cheaper.
• Reliability. What is the acceptable failure rate, and what happens when a retrieval or tool call fails?

These constraints bound every capability choice. An architecture that scores well across all eight dimensions but fails the latency or cost budget for the workload is over-engineered, not capable.

For the deliberate question of why the K-class set stops at K6 (and where memory, multimodality, temporal reasoning, reflection, multi-agent coordination, generation, and translation live instead), see Appendix A.

4.2 Knowledge preparation prerequisites

The capability stack assumes that retrievable evidence, queryable records, and traversable relationships exist in a form the system can use. They do not appear by accident. Document parsing, OCR, table and layout extraction, chunking strategy, metadata assignment, entity resolution, schema mapping, lineage capture, and index freshness all sit upstream of K0 and silently determine whether any K-class above can perform.

Knowledge preparation does not satisfy the §3.1 membership test for knowledge operations and is not itself a K-class. It is a layer-1 prerequisite (per §6.1) on which the operations above depend. A K1 system cannot enforce permission-aware retrieval if documents arrived without ACL metadata. A K3 system cannot reconcile contracts if the same legal entity appears as "Acme Inc.", "Acme, Incorporated", and "ACME INC" across the index without entity resolution upstream. A K4 system cannot compute over an authoritative record if the schema mapping conflates created_at and updated_at.

Three implications follow. First, KAS profiles for procurement and architecture should specify the preparation budget alongside the operation set; a K3+G3 workload over enterprise PDFs needs a layout-aware extraction pipeline before any K3 work begins to matter. Second, the most common reason K-class capability appears to fail in deployment is ingestion-side, not operation-side: the operation is correct but the inputs are malformed. Third, evaluation harnesses (§8.2) should test preparation quality independently from operation quality; otherwise improvements at one layer get attributed to the other.

5.1 K0 — Basic Retrieval

K0 systems retrieve unstructured chunks and summarize them: semantic search, prompt injection of retrieved context, generation with little or no validation. This is the classic naive RAG pattern, and most public RAG demos sit here. Its failure modes are well-understood — irrelevant chunks, hallucination when retrieval is weak,² poor source attribution, no awareness of when evidence is insufficient — and they motivate every K-class above. K0 systems are not deficient. They are the right shape for FAQ bots, document search, and simple policy lookup over public content. They become deficient only when deployed as the answer to a workload that needed K1's scoping or K3's contradiction handling.

(Absence of permission awareness is a property of K0, not a failure of it; K1 introduces scoped retrieval as a deliberate next step.)

5.2 K1 — Scoped Retrieval

K1 systems add control by scoping retrieval. They filter and rank evidence using metadata, permission filters, tenant boundaries, product scope, geography, date ranges, role, or other constraints.

Typical capabilities:

• metadata filtering;
• hybrid keyword/vector search;
• reranking;
• permission-aware retrieval;
• citations and source display.

Typical use cases:

• enterprise search;
• customer support scoped by product version;
• policy retrieval by region or role.

Main failure modes:

• stale metadata;
• incorrectly inherited permissions;
• over-filtering that hides relevant evidence.

5.3 K2 — Contextual Understanding

K2 systems preserve and operate over document structure. Instead of treating documents as flat chunks, they represent and use sections, headings, hierarchy, tables, appendices, and local scope.

Typical capabilities:

• hierarchical retrieval;
• section-aware QA;
• cross-section coherence (relating content in one section to its parent or sibling sections);
• local context preservation;
• provenance at section or paragraph level.

Typical use cases:

• contract interpretation;
• manual or policy analysis;
• technical documentation assistants.

Main failure modes:

• losing section boundaries;
• mixing obligations from unrelated parts of a document;
• weak table interpretation.

5.4 K3 — Cross-Source Synthesis

K3 systems combine evidence across documents and sources. They can compare, reconcile, summarize, and surface candidate contradictions for review. In enterprise settings, contradiction detection is rarely binary: most apparent contradictions stay unresolved until scope, authority, effective date, jurisdiction, and version precedence are known. Source authority is itself a first-class K3 input: a signed contract outranks a sales deck, a production database outranks a copied spreadsheet, an official policy outranks a Slack message. A K3 system that treats sources as equally weighted is averaging, not synthesizing.

Typical capabilities:

• multi-source retrieval;
• aligning evidence across sources around a shared subject (the system operates over entity resolution instead of performing it; entity resolution itself is a data-engineering and NLP problem upstream of the synthesis layer, and K3 systems consume its outputs);
• source mapping;
• candidate contradiction and scope-conflict detection (validated contradiction detection across enterprise documents, including temporal, jurisdictional, conditional, and version-scoped variants, remains a hard evaluation problem; K3 systems should surface candidates, not assert resolutions);
• comparative answers.

Typical use cases:

• comparing contracts;
• synthesizing market research;
• combining ticket history, product docs, and customer notes.

Main failure modes:

• flattening disagreement into false consensus;
• over-weighting recent or more verbose sources;
• weak provenance.

(Temporal reasoning is a frequent modifier at K3; see Appendix B.3 for boundary-case treatment.)

5.5 K4 — Computable Knowledge

K4 systems do not merely summarize text. They compute exact, executable answers from authoritative records. The knowledge operation is producing a verifiable result over structured data; in production today this almost always means delegating the computation to a system designed for it (a query engine, an API, a domain-specific calculator) instead of asking the LLM to compute internally. Tool-augmented LLMs that learn when to call APIs (Toolformer [10] and successors) push the boundary on this delegation, but LLM-internal computation with self-verification remains an active research direction, not yet a production pattern, and treating it as one is a recurring failure mode of K4 systems.

Typical capabilities:

• aggregation, filtering, and counting over authoritative records;
• exact numeric answers with traceable derivation;
• query validation and result verification;
• composing multi-step computations that an end user can audit.

Typical implementations:

• SQL generation against an enterprise database;
• Elasticsearch or domain-specific DSL queries;
• API calls to authoritative systems;
• domain-specific calculators or rules engines invoked as tools.

Typical use cases:

• analytics assistants;
• SLA reporting;
• financial exposure analysis;
• operational dashboards.

Main failure modes:

• invalid generated queries;
• schema misunderstanding;
• column-grounding errors (NL→SQL ambiguity, e.g., picking created_at when the user meant updated_at) [18];
• computing over the wrong source of truth;
• presenting unverified outputs as exact results (regardless of whether they came from a query or model inference).

(On the distinction between K4 result-verification and system-level claim-level fact-checking, see Appendix B.5.)

5.6 K5 — Relational Reasoning

K5 systems traverse and reason over relationships between entities. The knowledge operation is following chains of inference across connected facts, independent of whether those relationships are stored in a property graph, a relational schema with foreign keys, an RDF triplestore, or extracted on the fly from text.

Typical capabilities:

• multi-hop inference across entity relationships;
• dependency and lineage tracing;
• path explanation (showing which relationships justified the conclusion);
• relationship grounding (verifying claimed relationships against source data).

Typical implementations:

• property graph traversal (Neo4j, RDF, knowledge graphs);
• recursive SQL CTEs over relational schemas;
• knowledge-base traversal;
• hybrid graph + LLM-summarization approaches (e.g., GraphRAG [19]) and hybrid graph + vector retrieval combinations.

Typical use cases:

• software dependency analysis;
• supply-chain risk;
• legal entity ownership;
• fraud networks;
• infrastructure impact analysis.

Main failure modes:

• incomplete or partial relational coverage;
• stale relationships;
• schema drift / ontology mismatch between the relational model and the source data;
• path explosion;
• ranking traversal results by structural proximity (e.g., shortest path) rather than semantic relevance;
• mistaking traversal for validated reasoning (paths exist in the data but do not justify the inference).

5.7 K6 — Orchestrated Workflows

K6 is the K-class where the framework is tested hardest, because what makes a system K6 is not what it can do but what it decides to do in real time. A K6 system has a planning policy that, given a task, selects which K0–K5 operations to run, in what order, with what tools, and with what stopping criterion. The planning policy is the operation. A pipeline that hard-codes K0 → K3 → K4 with no choice point is not K6 even when it touches three K-classes (this is the meta-irreducibility argument settled in §A.2), and a system that wraps an LLM in a while loop with tool-calling is not K6 either if the loop has no policy beyond "keep going until done."

The two most-cited reasoning-and-acting patterns sit on the spectrum this distinction names. ReAct [20] interleaves a reasoning trace with tool actions inside a single chain. Its planning policy is "decide what to think about next given what just happened" — sufficient for short bounded tasks, but it degrades on long horizons because the policy has no memory of why earlier branches failed. Tree of Thoughts [21] generalizes the same idea into deliberate search over reasoning trajectories with explicit backtracking and a policy of "evaluate partial states, expand the most promising ones, prune the rest"; it pays a coordination cost ReAct does not. Production K6 systems borrow from both: ReAct-style traces inside individual sub-tasks, ToT-style search at the task-decomposition layer, and evaluator-optimizer loops [3] at the boundary between them. None of these is a complete blueprint. They are starting points for the planning policy a specific workload demands. Singh et al.'s agentic RAG survey [2] catalogues the productized variants; Anthropic's Building Effective Agents [3] catalogues the engineering patterns.

Typical capabilities — task decomposition and tool selection; evaluator-optimizer loops where an evaluator judges intermediate output and an optimizer revises the plan; recovery from tool failure (retry, substitute, escalate, abort); memory across steps (within-session at minimum, cross-session for case-based work); approval gates for consequential actions; and traceable plan execution that an auditor can reconstruct after the fact.

Typical use cases include customer support resolution workflows, research and compliance investigations, software engineering agents that touch real repositories, and revenue or churn-risk workflows that span retrieval, computation, and recommendation.

The failure modes are categorically harder than in single-operation systems. Unsafe autonomy and hidden tool failures are well-known. What receives less attention: reward / objective hacking, where the system optimizes a proxy of the goal (typically a high evaluator score) instead of the goal itself; circular planning, where the policy revisits a path it has already exhausted because it has no memory that it did so; escalating cost and latency from over-long traces or unnecessary parallel branches; and poor auditability when the planning trace is verbose enough to be present but disorganized enough to be unusable in a regulator-facing review. The first two are research-active. The last two are engineering problems most production K6 systems have not yet solved.

(Memory, multi-agent topologies, reflection, and the meta-irreducibility of K6 are recurring boundary-case questions; see Appendix A.2 and Appendix B.)

6.1 Five orthogonal layers

A workload profile becomes more rigorous when it distinguishes five independent layers, each of which can vary without forcing changes in the others:

1. Source of truth — documents, relational database, knowledge graph, API, ticketing system, observability store. What the system reasons over.
2. Access pattern — BM25, vector search, hybrid search, SQL, graph traversal, API call (the patterns enumerated in §6 above). How the system reaches the source.
3. Knowledge operation — retrieve, scope, structure, synthesize, compute, traverse, orchestrate (the K0–K6 framework in §5). What the system does with the evidence it reaches.
4. Control plane — permissions, provenance, evaluation, approval, audit (the governance scale in §9 and the evaluation discipline in §8). Under what constraints the system operates.
5. Consumer — human, agent, downstream system (the AX framing in §3.4). Who the system serves and what contract that consumer expects.

The KAS framework in this paper lives at layer 3 (operations). §6 patterns sit at layer 2. §9 governance and §8 evaluation are the control plane at layer 4. The AX discussion is layer 5. The five-layer view is what allows the same system to serve different workloads. A single retrieval engine (layer 2) can support a K1-only human-facing search (layers 3 and 5) and a K6 agent-facing orchestration (layers 3 and 5) by recomposing layers 3 and 4 without touching layer 1 or 2.

8.1 Answerability and abstention

Higher capability does not mean more answers. It means better control over when to retrieve, compute, escalate, or abstain.

A capable system should know when evidence is insufficient. And know here means produce an empirically calibrated signal, not a self-report of model confidence.

The table below is normative: it describes what a capable system at each class ought to do when evidence is insufficient. With the exception of the K0 row, these behaviors are not yet standard in deployed systems. Surfacing ambiguity, contradiction, incomplete paths, and conflict are active research and engineering frontiers, not commodity features. Self-reflective retrieval [26] and corrective retrieval [27] are early steps toward retrieval-control and critique at K1/K3; they do not yet constitute a solved production-grade abstention framework. Selective-prediction techniques are advancing toward K4 fail-closed behavior; agent benchmarks like GAIA [25] are surfacing the gap between K6 systems' demonstrated reasoning + tool-use performance and the level of reliability real-world deployments require.

8.2 Evaluation artifacts per capability class

The criteria in §8 describe what to test. Procurement and architecture teams need a more concrete answer: what artifacts must a vendor produce to demonstrate that a given K-class is exercised reliably on the buyer's data? The table below names the minimum artifact set per class. Each artifact is owned by the buyer, runnable on the buyer's corpus, and produced before the vendor passes acceptance. A vendor demo is not a substitute.

RAGAS [24], BIRD [18], and GAIA [25] provide reusable harnesses for retrieval/synthesis, K4 NL→SQL, and K6 tool-use respectively, but the test data must be drawn from the buyer's corpus to detect workload-specific failures the public benchmarks miss. A high score on a public benchmark is necessary, not sufficient.

9.1 Governance prerequisites by capability class

Not every capability class requires full governance, but certain classes make specific governance capabilities non-negotiable. The table below shows the minimum recommended governance level for responsible deployment at each capability class.

A first-order rule overrides every row in this table: the moment private or enterprise data is indexed, G1 becomes the practical floor regardless of capability class (basic citations and source IDs, at minimum so users can trace what was returned to them). G0 is acceptable only over public, non-sensitive data used for non-decision-support purposes (an FAQ over a public manual, a demo over open-domain content). The rows below describe minimum governance given the capability class; private-data sensitivity raises the floor independently.

These are floors, not ceilings. Regulated industries should treat G4 as the default baseline regardless of capability class. The K6 row is the most domain-sensitive: a code-completion agent and a payment-execution agent are both K6 systems, but they sit on opposite ends of the consequential-action spectrum and require very different governance.

This domain-sensitivity is general, not specific to K6. The governance floor for any workload is the maximum of five factors: data sensitivity (PII, PHI, financial, regulated content), action consequence (read-only versus reversible-write versus irreversible-or-financial), regulatory burden (HIPAA, SOX, GDPR, EU AI Act high-risk), reversibility (whether a wrong answer can be undone before it propagates), and automation level (human-in-the-loop, human-on-the-loop, fully autonomous). The K-class table sets the floor given the operation; this max-of-five formula sets the floor given the workload. Whichever is higher wins.

9.2 Threat model for KAS

The governance scale in §9 addresses correctness and accountability under good-faith inputs. It does not, by itself, address adversarial inputs. KAS systems also face a category of threats a buyer's RFP should explicitly cover. The OWASP Top 10 for LLM Applications [29] catalogues the application-layer risks; the table below maps the ones that affect KAS specifically to the capability layer where they land, with the mitigation pattern named in KAS terms.

A G-level alone does not capture adversarial robustness. A G5 system with no prompt-injection defenses is governed but unsafe. Threat-model coverage should be tested on the same evaluation cadence as the K-class artifacts in §8.2, and the test data should include adversarial fixtures the buyer constructs (not only public red-team corpora).

11.1 Financial services — two workloads, two profiles

Both workloads are "Financial Services" but require different vendor strengths, different governance baselines, and different architectural choices.

The single most expensive KAS-procurement error. Buying one platform to serve a portfolio that spans K1+K4 analytics and K1+K3+K5+K6 investigative work systematically over-pays for the analytics workload and under-serves the investigative one. Both pass surface-level vendor demos because the demo corpus exercises neither extreme. The fix is per-workload procurement, even when the workloads share an industry label. This is the most common failure mode named in §2.2 — disproportionate operation set in one direction, missing required operations in the other — and it is the one that motivates this paper's insistence on workload-level rather than industry-level evaluation.

11.2 Legal — two workloads, two profiles

11.3 Customer support — two workloads, two profiles

11.4 Software engineering — two workloads, two profiles

11.5 Compliance — two workloads, two profiles

The lesson across all five industries is the same: profile follows workload, not industry. Procurement decisions, vendor selection, and architectural investment should be made per-workload (or per-workload-class), not per-industry.

A second lesson is implicit in the contrasts above. Operational constraints (§4.1) form a parallel signature alongside the K-class profile, and two workloads with similar K-class shapes can sit on opposite ends of the latency, cost, and reliability budgets. The customer-support Resolution agent in §11.3 (K1+K3+K4+K6; G3) operates under interactive-latency caps that disqualify architectures the Litigation discovery synthesis workload in §11.2 (K1+K2+K3; G4) can absorb without difficulty, even though the latter's K-class profile is narrower and superficially "simpler". The capability-profile template (§13) should be filled in alongside the operational-constraint budgets, not as a substitute for them: a profile is a description of what the system does; an operational signature is a description of how fast, how cheaply, and how reliably it must do it.

12.1 Practical design guidance

• Start with task requirements, not architecture.
• Treat retrieval quality as a hard prerequisite.
• Add structure only where it improves correctness or controllability.
• Add computation only where exactness matters.
• Add graph traversal only where relationships are central to the task.
• Add orchestration only where dynamic multi-step workflows are required.
• Add autonomy slowly and with explicit constraints.
• Measure process quality, not just final-answer quality.
• Design for abstention and escalation.

12.2 Practical transition guidance

Organizations rarely upgrade capabilities in a clean sequence. Capability investment should be signal-driven, not stage-driven. Many systems will jump directly to higher-numbered operations without ever needing the intermediate ones.

• Retrieval quality (K0/K1). Invest when irrelevant or incorrect retrieval is the root cause of user-visible errors. This is a prerequisite only when retrieval is in scope at all; a NL→SQL analytics assistant may need almost no K0/K1 work.
• Structure preservation (K2). Invest when users consistently ask section- or clause-level questions and flat chunking is demonstrably failing them. A system can need K2 without ever needing K1 scoping (e.g., a public manual reader) and vice versa.
• Cross-source synthesis (K3). Invest when single-source answers are demonstrably incomplete and the cost of contradiction is non-trivial. Independent of whether structure preservation is in place.
• Computation (K4). Invest when exact, verifiable answers are required. A system can need K4 directly without any K0–K3 work; a NL→SQL analytics assistant over a clean schema is K4-dominant.
• Relational reasoning (K5). Invest when relationship traversal is the primary operation, not an incidental one. Independent of synthesis or computation; a software dependency analyzer is K5-dominant with little need for K3 or K4.
• Orchestration (K6). Invest when static pipelines cannot handle the dynamic, multi-step nature of the workload. Carries non-trivial latency, cost, and recovery complexity. K6 is justified by task dynamism, not by ambition.
• Governance. Advance in parallel with whichever capabilities are added; do not let it lag. A system that reaches K3 synthesis without G3 provenance is producing unchecked claims regardless of which other capabilities it has.

The pattern across these is that signals from the workload, not a desired position on a ladder, dictate which capability to invest in next. A system whose users never ask multi-hop relational questions has no business adding K5, no matter how sophisticated it sounds.

12.3 Vendor evaluation checklist

When evaluating a system or vendor against this model, ask:

1. Which capability dimensions does your system operate on? Can you demonstrate each with a live query against our documents (ingested under our metadata schema, with our access controls applied), not a vendor-prepared sample?
2. What is retrieval recall on our specific corpus (at recall@10 or recall@20, against a judgment set we own), not a benchmark corpus (BEIR, MTEB) and not recall@100 on a vendor demo set?
3. How does the system behave when evidence is insufficient? What is the false-abstention rate: how often does the system refuse to answer questions for which we know an answer exists in the corpus? A system that abstains on 40% of answerable questions to avoid hallucination is conservative, not capable.
4. Are access controls enforced at retrieval time or only at generation time? What happens if the retrieval layer returns unauthorized content? Show the code path.
5. How is provenance tracked across synthesis? Specifically: is citation at the chunk level, the passage level with character offsets, or the claim level (each sentence individually sourced)? For high-risk audit-grade workloads, claim-level provenance is the target state; passage-level citation may be sufficient when paired with reviewer approval and tamper-evident audit logs, but chunk-level alone rarely is.
6. What governance controls exist for tool calls and orchestration steps? Can individual tools be restricted by role or approval level? Are tool-call logs tamper-evident? Can the agent bypass approval gates under failure conditions?
7. What are per-query latency and cost at our expected volume and document scale? Provide P50, P95, and P99 latency, plus behavior under adversarial query patterns (very long documents, very broad queries), not just median against a vendor-curated workload.
8. How is correctness measured? Can we run our own evaluation set (with evaluation-set rights in the contract, not just in the conversation), and on a timeline compatible with our procurement window?
9. How does the system handle temporally-sensitive data? Specifically: does it detect stale sources at retrieval time or only at generation time? What is the measured lag between source update and index update? How does it answer as-of queries that fall outside the indexed historical range; does it surface "not valid as of " or silently return a current-as-of-now answer?

A.1 The membership test

A knowledge operation belongs at the K-class level when all of the following hold:

1. Verb at the system boundary. The system performs it; an agent or human can request it and observe a typed result. Not a property of inputs, not a topology of components.
2. Not constitutively tied to a single technology product or storage format. The same operation is implementable over vectors, graphs, SQL, APIs, or text, even if a given deployment chooses one.
3. Layer 3, not layer 1 or 2. What the system does, not what it stores or how it reaches the source (see §6.1).
4. Falsifiable at the boundary. A §8-style benchmark question and a §8.1-style recommended-failure-behavior row can be written for it.
5. Conceptually non-reducible to a single existing K-class without information loss. It is not a composition or recursion of existing K-class operations, except for K6, which is meta-irreducible (see A.2).

A.2 K6 meta-irreducibility

K6 is the only K-class whose substance is composition: planning over K0–K5 calls is irreducibly the operation, not the underlying calls it dispatches. A system that hard-codes a K0→K3→K4 sequence without a planner is a static pipeline that happens to use multiple operations, not K6. The carve-out is intentional: condition (5) above admits K6 because the planning policy itself is what is being tested, not the operations the planner dispatches.

A.3 Govern and Evaluate as layer-4 cross-cutters

Governance and Evaluation pass all five conditions of the membership test but are not assigned K-numbers. They operate as layer-4 cross-cutters: they wrap every K-operation instead of being one. They have their own scales (G0–G5 in §9 and the §8.1 normative table), and the §4 dimensions table lists them deliberately as cross-cutting instead of as K7 / K8. The K-class numbering accordingly stops at K6.

A.4 Excluded operation candidates

The three candidates readers most often nominate as missing K-classes, and where they actually live:

Other candidates surface less frequently and are dispatched in a sentence each. Planning is K6's primary verb (not a separate class). Multimodality and temporal reasoning are cross-cutting modifiers on every K-class (see the §8 footnote and Appendix B.3). Translation / format conversion is a layer-1/2 representation problem (§6.1). Verification / fact-checking is a sub-operation of Evaluate plus K4 result-verification (§8 and Appendix B.5). Generation is the LLM substrate every K-class assumes. Disambiguation / entity linking is the upstream NLP problem K3 explicitly defers to (§5.4). World-model construction and runtime online learning are research frontiers, not production-KAS verbs, and are out of scope.

A system that retrieves, synthesizes, computes, traverses, and orchestrates across these handled-elsewhere concerns is K0–K6; there is no missing K-class hiding in any of them.

B.1 Memory in K6

K6 systems that operate across turns, sessions, or users require a memory layer. Memory is a K6 sub-concern, not a distinct knowledge operation: a stateful K6 system requires the same planning, tool governance, recovery, and evaluation as a stateless one, plus session-state management with its own staleness, permission, and audit implications. Three rough scopes show up in practice: within-session (working memory across the steps of a single workflow); cross-session (episodic memory tied to a user or case); and cross-user (long-term semantic memory shared across the deployment). Each scope inherits the K-class's governance prerequisites; cross-user memory at K6 + G3 needs the same provenance and freshness checks as the underlying retrievals. The §13 template's Orchestration row should be answered together with "does this workload require stateful memory, and at what scope?"

B.2 Multi-agent topologies

K6 orchestration can be implemented by a single planner routing to tools, or by a network of specialized agents coordinating via message passing. The capability requirements (task decomposition, tool governance, failure recovery, human approval gates) are unchanged regardless of topology. Multi-agent architectures add coordination overhead and introduce agent-to-agent trust as a new governance concern (which agent can invoke which, with what approval level); these map to the existing K6 + G4/G5 cells in the §9.1 prerequisites table. Multi-agent is therefore a topology choice within K6, not a new K-class.

B.3 Temporal reasoning

K3 contradictions are frequently temporal: clauses that were superseded, policies that changed effective date, contracts amended after signing, regulatory rules with different in-force windows. Temporal reasoning (point-in-time validity, version reconciliation, "what was true on date X") is not a separate K-class but a cross-cutting modifier. It shows up most often inside K3 synthesis and §8.1 abstention behavior, and inside §9 G3 freshness checks. A K3 system that flattens "policy A says X" and "policy A v2 says ¬X" into a single contradiction without surfacing which version is currently in force has done a partial job. The §8.1 normative table includes a "Any class with temporal modifier" row precisely so that temporal failure modes are evaluable without inventing a K-class for them.

B.4 Reflection / self-correction

Reflection (the pattern where a system inspects its own intermediate output and decides whether to re-retrieve, re-plan, or revise) is the K6-internal application of Evaluate (§8) over the output of K0–K5. Self-RAG [26] and Corrective RAG [27] (cited in §8.1) are early productized forms; the operation is K6, the discipline is §8. Treating reflection as its own K-class would double-count the underlying Evaluate that already governs it.

B.5 Verification vs evaluation

Claim-level verification (checking a specific factual claim against an authoritative source) is a sub-operation of Evaluate (§8) and Govern (§9 G3 provenance), not a separate K-class. The §8 Evaluation row covers the system-level form (calibrated uncertainty / evidence-sufficiency); K4 result-verification covers the computational form. A system that conflates "the LLM thinks this is right" with "this claim has been grounded against a record" has lost the distinction; the §8 row's "ground individual factual claims against authoritative records when claims are factual" clause is the relevant test.