Programming Knowledge Native AI
Chapter 2

Knowledge as a Computational Primitive

To program with knowledge, a system must represent more than isolated facts. It must represent knowledge in a form that can progressively improve the system's understanding of the people, objects, processes, or situations it is reasoning about. This requires preserving enough meaning, provenance, scope, status, and operational structure for knowledge to participate directly in computation.

2.1 From Stored Knowledge to Knowledge That Shapes Computation

Software systems already contain many forms of knowledge. Databases store assertions about entities and events. Knowledge graphs encode relationships. Type systems express constraints. Rule bases describe conditions and consequences. Configuration files capture operational policies. Learned models preserve statistical regularities acquired from data.

Yet the presence of knowledge does not guarantee its computational use.

A constraint may be recorded but never checked. A retrieved passage may be added to a prompt without influencing the result. A model prediction may be accepted without testing whether it applies to the current case. A policy may appear in an explanation even though it played no role in the decision.

The distinction is between knowledge that is merely available and knowledge that participates in computation.

More precisely, the distinction is between knowledge that merely exists within the system and knowledge that changes its current understanding. A Knowledge Native program continually asks not simply, What knowledge do I have? but Which knowledge should become influential now?

Modern foundation models make this distinction even more important. A generative model may interpret observations, retrieve information, propose hypotheses, summarize evidence, or suggest actions. But those outputs become dependable only when explicit knowledge helps determine what is applicable, which constraints must hold, what evidence is still missing, and how competing conclusions should be reconciled. In Knowledge Native AI, knowledge does not replace the generative model; it shapes the computation around and through it.

Stored knowledge answers: What information is available?
Active knowledge answers: What role does this information play in the present computation?

For knowledge to become active, a system must be able to determine at least:

Knowledge Native AI is therefore not simply a method for attaching more information to a model. It is an attempt to give knowledge an explicit and inspectable role within computation.

2.2 What Makes Something a Computational Primitive?

A computational primitive is a basic kind of object that a programming system knows how to represent and manipulate.

Numbers support arithmetic and comparison. Strings support concatenation, parsing, and search. Sets support membership, union, and intersection. Relations support selection, projection, and join. Tensors support numerical transformation, differentiation, and composition.

These primitives are useful not merely because they store values. They are useful because the programming system defines meaningful operations over them.

Primitive and operation are inseparable. A number without arithmetic is little more than a symbol. A relation without relational operations is only a table. A tensor without transformations is only an array.

The same principle applies to generative AI components. A language model may interpret observations, generate candidate hypotheses, translate between representations, or synthesize explanations. Explicit knowledge determines which of those outputs should survive, which are constrained, which require further evidence, and which may become part of the system's evolving understanding.

If knowledge is to become a first-class computational primitive, it must likewise support a stable set of operations. A system should be able to identify knowledge, inspect it, select it, test its applicability, combine it, challenge it, revise it, and trace its consequences.

This does not require every kind of knowledge to share one physical representation. A compiler invariant, a financial rule, a sensor observation, and a model prediction are structurally different. The goal is not to flatten these differences, but to expose a common computational interface through which heterogeneous knowledge can participate in reasoning.

2.3 From Facts to Knowledge Objects

Consider the following assertion:

Package P depends on library L.

As ordinary data, this assertion might be stored as a row, an edge, or a field in a package manifest. That representation records the relationship, but it may not be sufficient for knowledge-aware computation.

A system may also need to know:

The bare fact records content. A knowledge object preserves the content together with the conditions and semantics required for its computational use.

Definition 2.1 (Knowledge Object). A knowledge object is an identifiable computational unit that carries content together with the provenance, scope, epistemic status, activation conditions, and operational structure required to influence an evolving computational understanding.

A knowledge object may be realized as a class, graph fragment, typed record, logical expression, database entity, structured message, or distributed resource. The definition concerns its computational role rather than its physical encoding.

A knowledge object may originate from a database, sensor, human expert, scientific publication, simulation, or the output of a generative AI model. Regardless of its origin, it participates through the same computational interface: its source, scope, status, applicability, and permitted effects remain explicit.

A minimal conceptual structure might be written as: 

KnowledgeObject
    identity
    content
    type
    provenance
    scope
    epistemic_status
    activation_conditions
    permitted_operations
    dependencies

This structure is not intended as a universal schema. It identifies the categories of information that commonly determine how knowledge may participate in computation.

2.4 The Anatomy of a Knowledge Object

Identity

A knowledge object must be individually addressable. Identity allows a system to refer to a particular observation, rule, claim, model output, definition, or judgment across multiple computational steps.

Without identity, it becomes difficult to preserve provenance, represent disagreement, revise an earlier assertion, or record that a later conclusion depended upon it.

For example, observation:fever:child-17:2026-07-18T21:10 identifies one clinical observation, while ais-event:vessel-204:loitering:031 identifies one operational event. The identifiers make each object individually revisable and traceable.

Content

The content is what the object asserts, describes, predicts, constrains, or provides.

Content may take many forms:

Knowledge Native computation does not require content to be expressed as natural language. Symbolic expressions, numerical structures, executable procedures, and graph patterns may all carry knowledge.

A content field might contain temperature = 39.2°C, vessel entered restricted zone, revenue_growth = 0.08, or the rule if dependency_version < 3.2 then incompatible.

Type

The type identifies what kind of knowledge the object represents. Examples include:

Type matters because different forms of knowledge admit different operations. An observation may update a state. A constraint may eliminate a candidate. A rule may derive a consequence. A hypothesis may accumulate support or challenge. A definition may determine classification.

In this sense, knowledge types play a role similar to types in programming languages: they constrain interpretation and identify which operations are meaningful.

For instance, rash_observed may be typed as an observation, possible_measles as a hypothesis, do_not_deploy as a constraint, and an LLM-generated summary as a model-produced interpretation.

Provenance

Provenance records where the object came from and how it entered the system. Its source may be a database, document, sensor, model, human expert, external service, or previous derivation.

Provenance is more than citation. It may affect authority, trust, reproducibility, conflict resolution, and auditability. Two objects with identical content but different derivations are not necessarily computationally interchangeable.

For example, a software compatibility claim inferred from a language model and the same claim obtained from an authoritative package manifest may have identical text but different permissible uses. Likewise, a clinical hypothesis proposed by a generative model and the same hypothesis supported by an authoritative guideline may require very different levels of verification before either can influence a recommendation.

A compact provenance record might read source = pediatric-guideline-2025, source = satellite-image-441, or source = llm:gpt-family:run-8821.

Scope

Scope states where, when, and under which conditions the knowledge applies.

Scope may be:

A tax rule may apply only during a particular year. A model may be valid only for data resembling its training distribution. A software invariant may apply only after initialization. A supply contract may govern one region but not another.

Without explicit scope, systems tend to overgeneralize knowledge that is valid only under limited conditions.

Examples include age_group = pediatric, jurisdiction = California, valid_for = software-v4.x, or region = South China Sea.

Epistemic Status

A knowledge object also requires some account of how it should be treated.

It may be:

Confidence may be one component of epistemic status, but it is not the whole of it. A high-confidence prediction remains a prediction. An authoritative rule may have no probabilistic confidence score at all. A low-noise measurement may still be obsolete because its validity period has expired.

A system might distinguish status = observed, status = llm-proposed, status = analyst-confirmed, and status = superseded, even when two objects carry similar confidence values.

Activation Conditions

Activation conditions specify when a knowledge object becomes relevant to the current computation.

A version constraint activates when resolving a particular package. A policy activates for users in a specified role. A numerical approximation may be valid only within a certain range. A model output may be usable only when required input conditions are satisfied.

Activation is what turns stored knowledge into active knowledge.

This is especially important when generative models produce several plausible interpretations or hypotheses. Activation determines which of those candidates become computationally influential by testing them against explicit knowledge, scope, prerequisites, constraints, and current evidence.

For example, a dehydration rule may activate only when age < 5 and reduced_urination = true; a maritime alert may activate only when loitering_duration > 90 minutes inside a protected zone.

Permitted Operations

The object should also expose or imply what the system may do with it. It may:

This is an important departure from treating knowledge as passive context. Knowledge does not merely appear near a computation. It participates through operations whose effects can be represented.

A dosage guideline may constrain an LLM-generated recommendation, a new sensor reading may challenge a vessel-behavior hypothesis, and a verified financial filing may support an analyst's forecast.

2.5 Knowledge Objects and Ordinary Data Objects

At first glance, a knowledge object may resemble an ordinary data object containing additional metadata. The difference is not the number of fields. It lies in what the programming system is expected to do with them.

An ordinary configuration record might contain: 

{
  "service": "billing-api",
  "version": "4.2",
  "region": "us-west"
}

A knowledge-aware representation might contain: 

{
  "id": "deployment:billing-api:4.2:us-west",
  "type": "deployment_observation",

  "content": {
    "service": "billing-api",
    "version": "4.2",
    "region": "us-west"
  },

  "provenance": {
    "source": "deployment-controller",
    "observed_at": "2026-07-18T10:14:00Z"
  },

  "scope": {
    "environment": "production",
    "valid_until_replaced": true
  },

  "epistemic_status": {
    "status": "observed",
    "confidence": 1.0
  },

  "permitted_operations": [
    "support",
    "challenge",
    "trigger_compliance_check"
  ]
}

The additional structure is not decorative. It determines behavior. The observation applies only to a particular environment. It may trigger a compliance check. A later deployment can supersede it. Its provenance can be included in a trace.

Data represents a value or state.
A knowledge object represents content together with the semantics and conditions of its computational use.

The distinction is analogous to the difference between bytes and typed values. The same bits acquire different meanings and permitted operations depending on their type. Knowledge objects extend this principle to provenance, scope, status, and consequence.

2.6 Knowledge Operations

Representing knowledge as an object is only half of the abstraction. A computational primitive becomes useful through the operations defined over it.

Definition 2.2 (Knowledge Operation). A knowledge operation is a typed computational action through which one or more knowledge objects affect a knowledge state, hypothesis, decision, derivation, or action.

These operations should be viewed as operations that change the system's current understanding. Some introduce new knowledge, others qualify existing knowledge, and others alter what the system should compute next.

A preliminary family of knowledge operations includes the following.

Construct

Create a knowledge object from an observation, document, model output, database record, rule, or human assertion. Construction assigns the identity and contextual structure required for later use. In generative systems, construction often includes grounding a model-produced statement, hypothesis, or plan into an explicit knowledge object before it is allowed to influence later computation.

For example, an LLM may suggest possible bacterial pneumonia. Rather than acting on that statement directly, the system constructs a knowledge object with provenance = llm, status = hypothesis, and scope = current encounter.

Retrieve

Locate knowledge that may be relevant to a task. Retrieval may be lexical, semantic, relational, graph-based, temporal, spatial, or rule-driven. It may return explicit knowledge from external sources as well as candidate interpretations or hypotheses produced by a generative model.

For example, a caregiver-assistance system may retrieve pediatric fever guidance, recent medication history, and prior observations; an operational system may retrieve vessel history, protected-zone boundaries, and weather conditions.

Retrieval produces candidates. It does not by itself establish that the retrieved knowledge applies.

Activate

Determine whether a candidate knowledge object is applicable in the current knowledge state. Activation evaluates scope, validity, prerequisites, and contextual conditions.

For example, a pediatric escalation rule may activate only when age < 5, fever_duration > 48 hours, and reduced_urination = true; a maritime alert may activate only after prolonged loitering inside a protected zone.

Support

Increase the justification for a claim or hypothesis. Support may be logical, empirical, statistical, causal, or authority-based.

For example, a positive culture may support a bacterial-infection hypothesis, while a verified satellite observation may support the hypothesis that two vessels conducted a rendezvous.

Challenge

Introduce knowledge that weakens, qualifies, or conflicts with a claim. A challenge need not prove the claim false. It may reduce confidence, expose a missing assumption, or require an alternative to be considered.

For example, normal oxygen saturation may challenge a severe-pneumonia hypothesis, while a fresh AIS transmission may challenge an earlier hypothesis that a vessel disabled its transponder.

Constrain

Restrict the set of permissible states, conclusions, plans, or actions.

For example, a documented drug allergy may constrain an LLM-generated treatment suggestion, a no-fly zone may constrain route planning, and a version dependency may block a software deployment.

In a compiler, a type rule constrains valid programs. In a scheduler, a resource limit constrains assignments. In a financial system, a policy may constrain allowable transactions.

Transform

Convert knowledge from one representation into another while preserving its identity and provenance.

For example, the phrase high fever may be grounded into temperature > 39°C, or the reference the large fishing vessel may be resolved to a specific vessel identifier.

Examples include converting source code into an abstract syntax tree, grounding a natural-language reference to a database entity, or translating a numerical score into a calibrated category.

Derive

Produce a new knowledge object from existing objects. A derivation should retain links to its inputs and to the operation that produced it.

For example, persistent fever, cough, elevated inflammatory markers, and an imaging finding may derive a new pneumonia hypothesis; repeated low-speed movement and close vessel proximity may derive a loitering or rendezvous event.

Reconcile

Resolve, prioritize, or explicitly preserve disagreement among knowledge objects. Reconciliation may use source authority, recency, scope, specificity, confidence, or domain-specific precedence. In a Knowledge Native generative system, this often means reconciling multiple model-proposed interpretations with symbolic rules, retrieved evidence, observations, and human judgment.

For example, an LLM may propose influenza while a laboratory result indicates RSV. The system may prefer the laboratory evidence while retaining influenza as a secondary, now-weakened hypothesis.

Revise

Modify the knowledge state when evidence, assumptions, or context change. Revision may update an object, supersede it, invalidate it, or propagate its changed status to dependent conclusions.

For example, a negative scan may revise the likelihood of appendicitis, while a new satellite image may revise a vessel's inferred destination or intent.

Explain

Expose the knowledge objects and operations that contributed to a result. Explanation should be grounded in a computational trace rather than reconstructed solely as plausible prose.

For example, a caregiver assistant might report: Hospital evaluation was recommended because the child's age, fever duration, reduced urination, and the pediatric escalation rule jointly changed the assessment.

These operations are not presented as a final knowledge algebra. Determining which operations are fundamental, how they compose, and what formal properties they should satisfy remains an open problem.

Research Question. What is the smallest useful set of composable operations through which heterogeneous knowledge can participate in computation?

2.7 Relevance Is Not Applicability

One of the most important distinctions in knowledge-aware computation is the difference between information that is related to a problem and knowledge that may legitimately be used within it.

A retrieved document may discuss the correct topic but refer to an obsolete software version. A policy may mention the current transaction but govern a different jurisdiction. A model may produce a prediction even though the input lies outside the model's intended domain.

Such information is relevant in a broad semantic sense, but not necessarily applicable.

Definition 2.3 (Applicability). A knowledge object is applicable when its scope, validity conditions, prerequisites, and epistemic status permit it to participate in the current computation.

Applicability may require checks such as:

This distinction is particularly important in systems built around retrieval. Similarity can locate potentially useful information, but similarity alone cannot determine computational authority.

2.8 Prompting Is Not Yet Computation

Modern language-model systems often assemble a context containing user messages, retrieved passages, model predictions, tool outputs, policies, and intermediate results. This can be effective because it gives the model material from which to produce a response.

Prompt engineering determines what information is presented to a foundation model. Knowledge Native programming determines how explicit knowledge shapes the computation before, during, and after model inference.

However, placing information in a context window does not specify the role that information played.

Suppose a prompt contains:

A language model may produce a plausible plan. Yet the surrounding system may not know whether the capacity limit eliminated an option, whether the delay notice reduced confidence, whether the analyst recommendation dominated the result, or whether one of the inputs was ignored.

Knowledge Native computation requires these relationships to be represented independently of the final prose response. 

claim: increase order quantity

supported_by:
    demand_forecast_18

challenged_by:
    supplier_delay_07

constrained_by:
    warehouse_capacity_04

revised_to:
    phased_order_plan_03

The context window may still support interpretation and synthesis. The language model may remain an important computational component. But the resulting relationships should be retained in a form that can be inspected, tested, revised, and reused.

Presence is not participation. Information appearing in a prompt is not evidence that it affected the computation in a known or controlled way.

2.9 A Minimal Programming Model

A minimal Knowledge Native program can be understood as a sequence of transformations over knowledge objects, knowledge state, and an evolving computational understanding. 

Observations and Requests
    ↓
Construct Knowledge Objects
    ↓
Generative Interpretation
    ↓
Retrieve Candidate Knowledge
    ↓
Activate Applicable Knowledge
    ↓
Apply Knowledge Operations
    ↓
Update Understanding
    ↓
Need more understanding?
    ├── Yes → observe, retrieve, generate, and reason again
    └── No  → generative projection:
              prediction
              plan
              recommendation
              alert
              explanation

The important shift is that the program does not move directly from either a model prompt or a collection of knowledge to a single output. Generative components help interpret observations, propose alternatives, and express results; explicit knowledge shapes which proposals become influential and how the system's understanding changes. Predictions, plans, recommendations, alerts, and explanations are then projected from that improved understanding.

  1. Construct knowledge objects from observations, databases, documents, rules, models, and human input.
  2. Retrieve objects potentially relevant to the current task.
  3. Activate only those whose applicability conditions are satisfied.
  4. Apply typed knowledge operations such as support, challenge, constrain, derive, and reconcile.
  5. Revise the knowledge state as new objects or consequences are introduced.
  6. Emit a result together with the trace of knowledge that produced it.

In simplified pseudocode: 

objects = construct_knowledge(
    observations,
    databases,
    documents,
    model_outputs
)

interpretations = generative_interpret(
    observations,
    task
)

objects.extend(
    ground_as_knowledge(interpretations)
)

candidates = retrieve(
    objects,
    task
)

active = [
    obj
    for obj in candidates
    if applicable(obj, task, knowledge_state)
]

understanding = apply_operations(
    state=knowledge_state,
    objects=active,
    operations=[
        support,
        challenge,
        constrain,
        derive,
        reconcile
    ]
)

understanding = revise(
    understanding,
    active
)

return project_output(
    understanding,
    task
).with_knowledge_trace()

This pseudocode intentionally hides difficult questions. How is applicability computed? How are uncertain claims combined? What is the formal meaning of support? How should conflicting constraints be resolved? When should revision invalidate a downstream result?

These are not secondary implementation details. They are central questions in the design of a Knowledge Native programming model.

2.10 Granularity and Composition

A practical issue is deciding what should count as one knowledge object.

A full policy document may be too coarse because its individual provisions have different scopes and effects. At the other extreme, treating every token, sentence, or graph edge as an independent object may obscure coherent meaning and make reasoning unwieldy.

A useful knowledge object usually satisfies three conditions:

Granularity may change during computation. A document may initially enter the system as one object, then be decomposed into claims, constraints, and definitions. Several fine-grained objects may later be composed into a larger policy, explanation, or plan.

Definition 2.4 (Knowledge Composition). Knowledge composition is the construction of a larger knowledge object from smaller objects while preserving the identities, roles, and provenance of the contributing parts.

Composition is important because intelligent computation moves across levels of abstraction. A system may reason over individual observations, intermediate hypotheses, and aggregate conclusions within the same task.

Larger knowledge objects often represent progressively richer understandings assembled from many smaller observations, constraints, hypotheses, and derived conclusions.

2.11 Knowledge Objects Need Not Be True

The phrase knowledge object should not be interpreted as a guarantee of truth.

An intelligent system must represent:

What makes these objects suitable for knowledge-aware computation is not certainty. It is that their epistemic status and conditions of use are represented.

A hypothesis may have low confidence. A claim may be disputed. A rule may have expired. A measurement may be noisy. A model output may be valid only within a limited domain.

Knowledge Native AI does not require every knowledge object to be accepted as true. It requires the system to represent what kind of object it is, why it is available, and how it may legitimately be used.

This ability to represent competing and provisional objects is essential. Reasoning frequently proceeds not from a single settled truth, but from an evolving collection of observations, assumptions, hypotheses, and constraints.

Knowledge Native Thinking

When encountering a source of information, ask not only what it contains, but what the computational system should be able to do with it.

A document is not yet an instruction. A graph edge is not automatically a constraint. A model score is not yet a conclusion. A human note is not automatically authoritative. A rule is not active merely because it is stored.

Knowledge Native Question. How should this knowledge improve the system's understanding, and how should it shape the generative, symbolic, statistical, and procedural components participating in the computation?

Once that question is asked, the design problem changes. The objective is no longer merely to move information into a model or pipeline. It is to program the conditions under which knowledge becomes active, the operations through which it shapes model interpretation and generation, and the trace through which its contribution remains visible.

Ask not simply how a language model should use a piece of information, but how explicit knowledge should shape every stage of the computation surrounding that model.

Chapter Summary

Discussion Questions

  1. Which properties of a knowledge object appear universal, and which are necessarily domain-specific?
  2. How is a knowledge object different from a typed record containing metadata?
  3. Can a learned model itself be represented as a knowledge object? What would its content, scope, and epistemic status be?
  4. Should activation conditions reside inside knowledge objects, in an external rule system, or in both?
  5. Can two knowledge objects with identical content legitimately support different operations because their provenance differs?
  6. What criteria should determine the appropriate granularity of a knowledge object?
  7. Which proposed knowledge operations are primitive, and which might be expressed as compositions of others?
  8. How might applicability be tested independently of semantic similarity?

Exercises

Exercise 2.1: Identify Hidden Knowledge

Choose a familiar software system. Identify at least five pieces of knowledge currently embedded in source code, configuration, prompts, model assumptions, or human procedures. For each one, state:

Exercise 2.2: Design a Knowledge Object

Represent the following statement as a knowledge object:

Version 4 of library L is incompatible with versions of package P earlier than 3.2.

Include at least:

Then identify two contexts in which the object is relevant but should not activate.

Exercise 2.3: Separate Relevance from Applicability

Suppose a retrieval system returns ten documents related to a software deployment. Design a procedure that distinguishes semantically relevant documents from knowledge objects applicable to the deployment decision. Include at least four applicability checks.

Exercise 2.4: Model Competing Knowledge

Create two knowledge objects that make conflicting claims about the expected delivery date of an order. Give them different sources, timestamps, scopes, and epistemic status. Describe a reconciliation procedure that does not simply select the object with the highest confidence score.

Exercise 2.5: Specify a Knowledge Operation

Choose one operation—support, challenge, constrain, derive, or revise—and write a precise informal specification for it. Your specification should identify:

Exercise 2.6: Implement a Minimal Class

Write a small class for a knowledge object. Include fields for identity, content, type, provenance, scope, epistemic status, activation conditions, and dependencies. Add an applies_to(context) method and use the class to represent one observation, one constraint, and one derived claim.

Exercise 2.7: Construct a Knowledge Trace

Construct a short reasoning trace containing:

Show exactly which objects contributed to the final conclusion and which operation each object performed.