Chapter 3

Thinking in Knowledge

How problem formulation changes when explicit knowledge and generative models work together to build, test, and progressively improve an understanding.

3.1 Abstractions Change How We Think

Computer science advances not only through faster machines or more powerful algorithms, but through better abstractions. An abstraction gives programmers a new vocabulary for describing computational problems. Once introduced, it changes what can be expressed naturally, what can be hidden safely, and which operations become available.

Procedural programming encouraged programmers to think in sequences of instructions. Object-oriented programming foregrounded objects, state, interfaces, and behavior. Functional programming emphasized transformation, composition, and immutable values. Relational databases replaced direct manipulation of files with relations and declarative queries. Machine learning made it possible to express some computations through models learned from examples rather than through explicitly written rules.

Each of these developments altered more than implementation. It altered problem formulation.

A programmer working with files may ask where a record is stored. A programmer working with relations asks which tuples satisfy a predicate. A programmer working with objects asks which entity owns a behavior. A programmer working with a learned model asks which function can be estimated from data.

Knowledge Native AI proposes another shift in viewpoint. Instead of asking only:

What computation should the system perform?

we also ask:

What is the system currently trying to understand? What observations, explicit knowledge, and model-generated interpretations shape that understanding? What remains uncertain? What should the system observe, infer, retrieve, verify, or ask next?

Definition 3.1 (Thinking in Knowledge). Thinking in knowledge is the practice of formulating computational problems around an evolving understanding: how observations, generative interpretations, explicit knowledge, constraints, uncertainty, and revision progressively change what the system believes about the subject of reasoning.

This does not eliminate ordinary computation. Algorithms, data structures, databases, and models remain essential. The shift is that they are treated as participants in a larger process through which the system constructs, tests, and revises an operational understanding of a person, object, situation, process, or phenomenon.

3.2 Representation Exposes Computation

A foundational lesson of computer science is that representation determines computation. The same underlying information may admit very different operations depending on how it is represented.

A graph stored as an adjacency matrix supports constant-time edge lookup but may consume substantial space. The same graph stored as adjacency lists makes traversal efficient for sparse structures. A mathematical expression stored as text is different from the same expression represented as an abstract syntax tree. A collection of observations stored as isolated strings is different from the same observations represented as typed, linked, and revisable knowledge objects.

Representation is therefore not merely a storage decision. It determines which questions are easy to ask, which invariants can be enforced, which transformations are composable, and which dependencies can be followed.

Computer Science Principle. Representation does not merely preserve information. It exposes a particular space of possible computations.

The same principle applies to knowledge. When knowledge exists only implicitly in prose, application code, model parameters, prompts, or developer assumptions, the system may make use of it without being able to inspect or manipulate it directly. It may be unable to identify the source of a claim, compare it with competing claims, determine its scope, trace which conclusions depend upon it, or revise those conclusions when the claim changes.

Once computationally important knowledge is represented explicitly, additional operations become possible. A model-generated interpretation can be grounded. A claim can be connected to evidence. A constraint can be checked against a proposed action. Two sources can be reconciled. A knowledge gap can determine the next question. A changed observation can propagate to affected conclusions.

This does not require all knowledge to be symbolic or stored in a graph. The essential requirement is that the aspects of knowledge that materially affect computation become accessible to the system.

3.3 From Values to Knowledge-Bearing Values

Traditional programs manipulate values:

# Caregiver observation
temperature = 39.2
rash_present = True

# Operational observation
speed = 1.8
location = "protected_zone_14"

In an ordinary program, the surrounding code supplies the interpretation. The programmer knows what each variable refers to, where it came from, when it was measured, and what operations are appropriate.

In knowledge-intensive computation, the value alone may be inadequate. The system may also need to know:

where the value originated;
when it was observed or computed;
which entity and situation it concerns;
how reliable or authoritative it is;
whether it remains valid;
which assumptions were used to produce it; and
which later conclusions depend upon it.

Definition 3.2 (Knowledge-Bearing Value). A knowledge-bearing value is a value represented together with enough semantic and contextual information to determine how, where, and under what conditions it may participate in computation.

Caregiver assistance. The value 39.2°C becomes more useful when represented together with the child's age, the time of observation, the measurement method, and the fact that it was reported by a caregiver rather than measured in a clinic.

Operational intelligence. The value 1.8 knots becomes meaningful when connected to a particular vessel, a protected-zone location, a seventy-four-minute duration, the AIS source, prevailing weather, and a current hypothesis of loitering.

A knowledge-bearing value need not contain every imaginable annotation. It contains the contextual information required by the computations in which it participates. Depending on the problem, that may include provenance, time, confidence, scope, evidence, authority, validity conditions, or dependencies.

This resembles the distinction between an untyped memory location and a typed value. The raw bits may be identical, but the type constrains their interpretation and the operations that may be applied. Knowledge-bearing values extend this idea beyond type to computational meaning.

3.4 From Program State to Understanding State

Programs evolve by changing state. Variables are assigned, objects are modified, files are written, and database rows are updated. Program state captures what is currently true about execution.

Knowledge Native systems also maintain what is currently observed, believed, supported, uncertain, contradicted, constrained, or unresolved about the subject being addressed.

Definition 3.3 (Knowledge State). A knowledge state is the system's current structured representation of the entities, observations, claims, hypotheses, constraints, uncertainties, and unresolved questions relevant to a computational task.

A knowledge state may contain far more than is relevant to one immediate problem. An understanding state organizes the active portion of that knowledge around the particular person, object, situation, process, or phenomenon currently being reasoned about.

Definition 3.4 (Understanding State). An understanding state is the task-focused organization of current observations, interpretations, hypotheses, evidence, constraints, uncertainties, and knowledge gaps concerning a particular subject of reasoning.

Observations
      ↓
Generative Interpretation
      ↓
Current Understanding
      ↓
Knowledge Operations
      ↓
Revised Understanding
      ↓
Further Inquiry or Projection

Caregiver assistance.

Observation:
fever + rash

Current understanding:
acute febrile illness;
cause and severity unresolved

Knowledge gaps:
breathing difficulty?
hydration?
rash character?
vaccination status?

Next computation:
generate targeted caregiver questions

Operational intelligence.

Observation:
repeated low-speed movement

Current understanding:
possible loitering;
intent unresolved

Knowledge gaps:
weather conditions?
nearby vessels?
protected-area status?
historical behavior?

Next computation:
retrieve discriminating evidence

This formulation changes the role of computation. A new observation does not merely produce another output. It changes the context within which earlier and later interpretations must be evaluated.

3.5 Decomposing Problems Through Knowledge Operations

Chapter 2 introduced operations such as construction, retrieval, activation, support, challenge, constraint, transformation, derivation, reconciliation, revision, and explanation. Thinking in knowledge means using those operations as a vocabulary for decomposing how an understanding should evolve.

The design problem is no longer simply to decide which model to call or which prompt to construct. It is to determine how candidate interpretations enter the system, what makes them applicable, what supports or challenges them, how conflicts are reconciled, and how the resulting understanding may later be revised.

Conventional formulation	Knowledge Native formulation
Classify the case	Construct and test competing interpretations
Retrieve relevant text	Retrieve potentially applicable knowledge and determine what activates
Generate an answer	Project an answer from the current understanding
Handle missing input	Represent a knowledge gap and determine what to ask or observe next
Re-run after a change	Revise the affected region of understanding incrementally
Explain the result	Expose the knowledge trace that actually produced it

Abstraction Criterion. A useful knowledge abstraction exposes a small set of stable operations while hiding unnecessary representational detail.

Different implementations may represent a claim as a graph fragment, a typed record, a logical expression, or a structured document. The knowledge-level operation should preserve its conceptual meaning across these representations.

The aim is therefore not to scatter knowledge-related behavior across prompts, model calls, database queries, and conditionals. It is to make the role of knowledge visible and programmable across the entire computation.

3.6 Knowledge Dependencies and Incremental Understanding

Dependency is already a central computational idea. Build systems record which artifacts depend on which source files. Spreadsheets track which cells depend on other cells. Compilers construct dependency graphs among declarations and expressions. Incremental databases update derived views when source relations change.

Understanding also has dependencies. A conclusion may depend on several observations. A behavioral hypothesis may depend on environmental assumptions. A recommendation may depend on both a derived claim and a policy constraint. An explanation may depend on the continued availability of the evidence that supported the original result.

Definition 3.5 (Knowledge Dependency). A knowledge dependency records that the validity, applicability, confidence, or interpretation of one knowledge object depends upon another.

Caregiver assistance.

Caregiver observation
        ↓
Evidence of dehydration
        ↓
Severity assessment
        ↓
Triage recommendation

If “normal urination” is revised to “no urination for ten hours,” the downstream severity assessment and triage recommendation must be reconsidered.

Operational intelligence.

AIS observations
        ↓
Loitering hypothesis
        ↓
Possible rendezvous behavior
        ↓
Operational alert

If newly retrieved weather data explains the low-speed movement, the loitering hypothesis weakens and the downstream alert may no longer be justified.

Explicit dependencies make revision computationally manageable. The system need not reconstruct its entire understanding after every change. It can identify and update the affected region.

This connection to incremental computation is important. Knowledge reasoning is sometimes presented as separate from conventional systems research. In practice, many of its challenges resemble familiar problems in view maintenance, dependency tracking, invalidation, caching, and change propagation.

3.7 Knowledge Roles in a Generative Architecture

Knowledge in a modern AI system is rarely located in one place. It may be distributed across databases, documents, learned models, graphs, rules, source code, external services, sensors, simulations, and human judgment.

A Knowledge Native architecture does not require these sources to become identical. Instead, it makes their roles in constructing, testing, revising, and using knowledge explicit.

Definition 3.6 (Knowledge Role). A knowledge role describes how a computational component contributes to the creation, interpretation, storage, transformation, validation, revision, or projection of knowledge.

A database may serve as persistent memory. A graph may represent relationships and dependencies. A rule engine may activate constraints. A numerical model may estimate an unknown quantity. A simulator may test counterfactual conditions. A human reviewer may resolve ambiguity or supply authoritative judgment.

A foundation model may occupy several roles within the same process. It may:

interpret natural-language or multimodal observations;
propose candidate hypotheses;
identify possible knowledge gaps;
formulate the next question or tool call;
translate between human and structured representations; and
project explanations, recommendations, or plans from the current understanding.

Explicit knowledge then grounds those interpretations, checks applicability, activates constraints, challenges unsupported hypotheses, preserves dependencies, and controls what becomes part of the evolving understanding.

Architectural Shift. The foundation model is neither the entire reasoner nor merely a user interface. It is a flexible computational component whose interpretations and projections are shaped by an explicit knowledge process.

The components need not compete to become the sole reasoning mechanism. They occupy complementary roles within a shared process of understanding.

3.8 Revision, Versioning, and Time

Software systems already treat change as a first-class concern. Databases provide transactions. Version-control systems preserve histories. Event-sourced architectures record transitions. Distributed systems reason about ordering, consistency, and stale replicas.

Knowledge changes as well. Observations become outdated. Sources are corrected. Assumptions cease to hold. New evidence strengthens or weakens earlier interpretations.

Definition 3.7 (Knowledge Revision). Knowledge revision is the controlled modification of a knowledge state or understanding state in response to new evidence, changed assumptions, corrected sources, or altered context.

Caregiver assistance. A caregiver initially reports no breathing difficulty, then observes labored breathing. The earlier low-risk assessment should not merely be overwritten. The system should preserve what was previously believed, revise the affected severity interpretation, and propagate that change to the escalation recommendation.

Operational intelligence. A vessel initially appears to be loitering, but newly retrieved weather data shows severe currents. The system should weaken the behavioral hypothesis while retaining why it was previously considered plausible.

Revision is therefore not equivalent to assigning a new value. If one claim supported other claims, changing it may invalidate conclusions, reduce confidence, reopen a question, or require additional evidence.

Versioning becomes part of reasoning. An explanation of a past decision should be grounded in the knowledge available when that decision was made, not only in what the system knows now.

The analogy with source control remains useful. A mature Knowledge Native system may need to preserve historical states, alternative interpretations, branches of inquiry, reconciliations, and the consequences of each revision.

3.9 Knowledge Gaps and Productive Uncertainty

Traditional programs are often designed around complete inputs. When a required value is absent, the program may fail, return a null value, or apply a default.

Knowledge-intensive systems routinely operate under incomplete information. Missing knowledge is not merely an exceptional condition. It may determine what the system should do next.

Definition 3.8 (Knowledge Gap). A knowledge gap is an explicitly represented absence of information whose resolution may affect the validity, confidence, applicability, or direction of an understanding.

A knowledge gap is more informative than an unknown value. It may specify what is missing, why it matters, which hypotheses depend upon it, and how it could be resolved.

Unknown hydration status
        ↓
Generate caregiver question

Unknown nearby-vessel relationship
        ↓
Retrieve encounter history

Conflicting model interpretations
        ↓
Seek discriminating evidence

This is a natural point of interplay between explicit knowledge and generative AI. A language model may formulate a fluent question, but explicit knowledge determines which gap matters, why it matters, and what answer would materially change the current understanding.

Productive Uncertainty. A well-represented uncertainty is not merely a limitation. It is a computational instruction about what should be observed, retrieved, verified, or asked next.

3.10 Knowledge Traces and Explanation

An output alone rarely reveals the structure of the computation that produced it. Conventional systems address this through logs, stack traces, provenance records, and execution plans.

Knowledge Native systems require an analogous mechanism for reasoning.

Definition 3.9 (Knowledge Trace). A knowledge trace is a structured record of the knowledge objects, dependencies, operations, and revisions that contributed to a computational result.

A knowledge trace is not necessarily a natural-language explanation. It is the computational structure from which explanations can be generated.

A model-generated rationale is also not automatically a knowledge trace. It may be plausible prose without corresponding to the actual objects and operations that influenced the result.

A proper trace records what truly participated: which observations were constructed, which knowledge was retrieved and activated, which hypotheses were supported or challenged, which constraints fired, and which revisions changed the result. A language model may then render that trace into language appropriate for a caregiver, analyst, engineer, scientist, or auditor.

Knowledge traces support:

debugging incorrect conclusions;
identifying stale or weak evidence;
comparing alternative derivations;
auditing consequential decisions;
generating audience-appropriate explanations; and
revising affected conclusions when knowledge changes.

Explanation therefore becomes part of the computational design rather than a narrative improvised after the fact.

3.11 Selective Explicitness

Treating knowledge as first-class does not mean representing everything explicitly. Such a goal would be unnecessary, expensive, and often counterproductive.

Definition 3.10 (Selective Explicitness). Selective explicitness is the principle that knowledge should be represented explicitly when its provenance, scope, uncertainty, constraints, dependencies, or consequences materially affect computation.

A practical criterion is to make knowledge explicit when it can change:

what a model is allowed to infer;
what evidence should be gathered;
which hypotheses remain viable;
which actions are permissible;
what must be revised after new information arrives; or
what must be explained afterward.

A temporary loop counter is ordinarily just data. A model-generated classification that triggers a costly or consequential action may need to be represented as a claim with provenance, evidence, status, and dependencies. A fixed arithmetic constant may remain ordinary code. A policy that varies across jurisdictions or time may require explicit scope and versioning.

The objective is not to convert the entire world into a knowledge graph. It is to expose the knowledge structures that give the system computational leverage: structures that materially affect reliability, adaptability, and accountable action.

3.12 A Method for Thinking Like a Knowledge Native Programmer

A conventional programmer often begins by asking which data structures, algorithms, models, databases, or services are required. A Knowledge Native programmer asks those questions, but begins one level earlier.

1. Identify the Subject of Understanding

What person, object, process, situation, or phenomenon is the system trying to understand?

2. Describe the Current Understanding

What is presently observed, believed, hypothesized, constrained, contradicted, or unresolved?

3. Identify Knowledge Sources and Computational Roles

What comes from observations, databases, documents, learned models, rules, simulations, external services, and humans? What role does each source play?

4. Identify Gaps and Competing Interpretations

What is missing? Which alternatives remain viable? What evidence would distinguish among them?

5. Specify How Understanding May Change

What can support, challenge, constrain, derive, reconcile, or revise the current understanding?

6. Specify Projections from Understanding

What dialogue, prediction, plan, recommendation, alert, action, or explanation may be produced from the current understanding?

Caregiver assistant. The subject is the child's present condition. The current understanding contains fever and rash but unresolved severity. The important gaps concern hydration, breathing, and rash character. Explicit triage knowledge determines which questions matter and which observations activate escalation. A language model conducts the dialogue and expresses the resulting recommendation.

Operational intelligence. The subject is the evolving behavior of a vessel group. The current understanding contains low-speed movement and repeated proximity, but several interpretations remain viable. Environmental data, geographic knowledge, vessel history, and operational rules support or challenge those interpretations. A model helps synthesize the observations and project an analyst-facing explanation.

This method changes decomposition. A problem is no longer divided only into ingestion, model inference, business logic, and output generation. It is decomposed into observation, interpretation, grounding, activation, derivation, validation, revision, inquiry, and projection.

Thinking in knowledge exposes assumptions that would otherwise remain embedded in prompts, code, workflows, or human procedures. Once exposed, those assumptions can be tested, revised, shared, and reused.

Central Thesis. Knowledge Native AI is not primarily about adding knowledge to AI. It is about programming how explicit knowledge and generative models jointly construct and progressively improve an understanding.

Chapter Summary

Programming abstractions change how computational problems are formulated.
Representation determines which knowledge operations become possible, natural, and reliable.
Knowledge-bearing values extend ordinary values with computationally relevant meaning and context.
Knowledge state records what is available; understanding state organizes what is currently believed about a particular subject.
Knowledge operations provide a vocabulary for programming how understanding evolves.
Knowledge dependencies make revision and consequence propagation incremental.
Foundation models, databases, graphs, rules, simulations, and humans can occupy distinct knowledge roles within one architecture.
Revision, versioning, uncertainty, and explanation are part of the computation itself.
Knowledge gaps can determine the next observation, retrieval, verification, or question.
Knowledge traces record actual computational participation rather than merely plausible rationale.
Selective explicitness keeps Knowledge Native systems practical.
Thinking in knowledge begins by asking what is being understood, what shapes that understanding, and how it should change next.

Discussion Questions

How does treating understanding as computational state change the formulation of an AI problem?
Why is knowledge representation a computational decision rather than merely a storage decision?
How does a knowledge-bearing value differ from an ordinary typed value?
What is the difference between a broad knowledge state and a task-focused understanding state?
How do explicit knowledge and generative models play different but complementary roles?
How do knowledge dependencies support incremental revision?
When should a model output become an explicit knowledge object?
Why is a model-generated rationale not necessarily a knowledge trace?
How can a knowledge gap determine the next computation?
What are the risks of making too much information explicit?

Exercises

Choose a familiar AI system and identify the person, object, process, or situation it is actually trying to understand. Describe its current understanding state.
Convert three ordinary program values into knowledge-bearing values. For each, identify which contextual fields are computationally necessary.
Construct a small dependency graph for a clinical, operational, scientific, educational, or financial application. Show how one changed observation propagates to at least two downstream conclusions.
Identify the knowledge roles played by a language model, a database, a graph, a rule engine, and a human reviewer in one application.
Describe a knowledge gap that should trigger a question, retrieval, observation, or verification step rather than a default value.
Take an application from your own domain and reformulate it using the six-step method in Section 3.12.
Design a knowledge trace for one consequential recommendation. Distinguish the trace itself from the natural-language explanation shown to the user.