A First Knowledge-Native Program

The previous chapters developed the abstractions. We can now write a Knowledge Native program. The program will maintain an explicit understanding, activate knowledge and computational expertise as the situation evolves, apply that expertise, absorb what it establishes, and authorize only those recommendations or actions for which the required computational grounds exist.

The important point is not that every application must use an LLM, ontology, rule engine, predictor, planner, or verifier. Different applications need different expertise. The common programming model is that knowledge determines what matters, appropriate expertise performs the computation, its result becomes part of the evolving understanding, and that understanding determines what the system may do next.

7.1 The Program We Are Building

Our first program needs only a few abstractions:

KnowledgeObject
    something known, observed,
    predicted, proposed, or established

KnowledgeCapsule
    reusable declaration of
    knowledge + applicability +
    expertise + result semantics

ComputationalExpert
    performs a bounded computation

UnderstandingState
    current computational understanding

Runtime
    ACTIVATE
    APPLY
    ABSORB
    AUTHORIZE

These abstractions deliberately hide a great deal.

The program does not need to know how an LLM provider schedules inference, how a trajectory model executes on a GPU, how a planner searches its state space, or how a verifier proves a property.

It needs to know:

• when that expertise matters;
• what knowledge it requires;
• what it can establish;
• how to interpret its result;
• and what authority that result may contribute.

7.2 A Small Runtime

We begin with a deliberately small Python representation.

from dataclasses import dataclass, field
from typing import Any, Callable


@dataclass
class KnowledgeObject:
    key: str
    value: Any
    status: str
    provenance: str


@dataclass
class ExpertResult:
    result_type: str
    payload: dict[str, Any]
    epistemic_status: str
    expert_id: str
    provenance: list[str] = field(default_factory=list)


@dataclass
class Understanding:
    subject: str
    facts: dict[str, KnowledgeObject] = field(default_factory=dict)
    results: list[ExpertResult] = field(default_factory=list)
    gaps: set[str] = field(default_factory=set)
    authority: dict[str, str] = field(default_factory=dict)

    def value(self, key):
        item = self.facts.get(key)
        return item.value if item else None

    def known(self, key):
        return key in self.facts


@dataclass
class ComputationalExpert:
    id: str
    fn: Callable[[Understanding], ExpertResult]

    def apply(self, understanding):
        return self.fn(understanding)


@dataclass
class KnowledgeCapsule:
    id: str
    applicable_when: Callable[[Understanding], bool]
    requires: list[str]
    expert_id: str
    result_type: str
    authority_role: str = "advisory"

This is not intended as the final KnaiTai API. It exposes just enough structure to make the programming model concrete.

7.3 Implementing A4

The runtime can now implement the four semantic operations.

ACTIVATE

def activate(capsules, understanding):

    active = []

    for capsule in capsules:

        if not capsule.applicable_when(understanding):
            continue

        missing = [
            requirement
            for requirement in capsule.requires
            if not understanding.known(requirement)
        ]

        active.append({
            "capsule": capsule,
            "ready": not missing,
            "missing": missing
        })

    return active

ACTIVATE does two things.

It determines which reusable knowledge/expertise declarations apply to the current situation, and it exposes missing requirements when relevant expertise is not yet ready to run.

APPLY

def apply(active_item, experts, understanding):

    capsule = active_item["capsule"]

    if not active_item["ready"]:
        return None

    expert = experts[capsule.expert_id]

    return expert.apply(understanding)

APPLY knows almost nothing about the expert's implementation.

The expert could internally call:

Claude or another frontier LLM
PyDatalog
OR-Tools
a trajectory transformer
a numerical simulator
a constraint solver
a model checker
SQL
ordinary Python
a remote API
a human review workflow

That heterogeneity is hidden behind the expert interface.

ABSORB

def absorb(understanding, result):

    if result is None:
        return understanding

    understanding.results.append(result)

    for key, value in result.payload.items():

        understanding.facts[key] = KnowledgeObject(
            key=key,
            value=value,
            status=result.epistemic_status,
            provenance=result.expert_id
        )

        understanding.gaps.discard(key)

    return understanding

This first version is intentionally simple.

A production ABSORB implementation would also preserve dependencies, supersession, conflicts, assumptions, validity scope, and richer epistemic semantics.

The important point is conceptual:

AUTHORIZE

def authorize(
    understanding,
    target,
    requirements
):

    missing = [
        requirement
        for requirement in requirements
        if not understanding.known(requirement)
    ]

    if missing:
        understanding.authority[target] = "WITHHELD"

        return {
            "target": target,
            "allowed": False,
            "missing": missing
        }

    understanding.authority[target] = "ALLOWED"

    return {
        "target": target,
        "allowed": True,
        "missing": []
    }

This too is deliberately minimal.

Real authority conditions may require particular expert results, successful verification, absence of blocking constraints, human approval, or other domain-specific assurance.

7.4 The Generic Runtime Loop

The pieces now form a small Knowledge Native loop.

def update(
    understanding,
    capsules,
    experts,
    authority_target=None,
    authority_requirements=None
):

    active = activate(
        capsules,
        understanding
    )

    for item in active:

        if not item["ready"]:

            understanding.gaps.update(
                item["missing"]
            )

            continue

        result = apply(
            item,
            experts,
            understanding
        )

        understanding = absorb(
            understanding,
            result
        )

    authority = None

    if authority_target:

        authority = authorize(
            understanding,
            authority_target,
            authority_requirements or []
        )

    return understanding, authority

The runtime does not ask one model to perform every operation.

It also does not prescribe a fixed chain of experts.

Each update begins again from the current understanding.

7.5 Example One: An After-Hours Caregiver Assistant

Consider a caregiver assistant for a parent trying to decide what to do when a child becomes unwell after normal clinic hours.

The foundation model can perform most of the conversational work. It can interpret descriptions, maintain dialogue, explain terminology, and reason broadly about the situation.

Knowledge Native architecture does not attempt to replace that capability.

Instead, the application makes selected knowledge computationally explicit where the developer wants stronger control over the recommendation boundary.

Stage 1: The Caregiver's Initial Situation

“My six-year-old has had a fever and threw up twice. She's drinking now and watching TV. Can I just monitor her tonight?”

The conversational expert constructs observations:

subject:
    child-17

age:
    6

fever:
    true

vomiting:
    2 episodes

responsive:
    true

drinking:
    true

requested_disposition:
    home_monitoring

Stage 2: Declare the Critical Knowledge

The application contains a general disposition capsule.

Notice that the declaration contains no reference to child-17.

id: home-monitoring-readiness

scope:
  domain: pediatric_caregiver

applicable_when:
  requested_disposition: home_monitoring

requires:
  - responsiveness
  - hydration_status
  - respiratory_status

expertise:
  id: home_monitoring_evaluator

result:
  type: disposition_readiness

authority:
  role: constraining

Stage 3: ACTIVATE Exposes Missing Knowledge

The caregiver has asked whether home monitoring is appropriate.

ACTIVATE therefore considers the disposition capsule.

home-monitoring-readiness

applicable:
    yes

requirements:

    responsiveness
        ✓

    hydration_status
        approximately established

    respiratory_status
        UNKNOWN

activation:
    NOT_READY

The crucial point is not that a frontier model is incapable of asking about breathing.

It very likely can.

The stronger architectural statement is:

Stage 4: APPLY Conversational Expertise

The language model remains the natural expert for asking the caregiver the required question.

How is she breathing?

Is it comfortable and normal for her, or is she breathing much faster
than usual or pulling in around or between the ribs?

The caregiver answers:

“She is breathing faster than normal.”

Stage 5: ABSORB Changes the Understanding

{
  "key": "breathing_rate_description",
  "value": "faster_than_normal",
  "status": "caregiver_reported",
  "provenance": "conversation:turn_2"
}

The result is absorbed.

That new state makes more specific respiratory expertise applicable.

ABSORB

    faster breathing

        ↓

understanding changed

        ↓

ACTIVATE

    respiratory assessment expertise

Stage 6: APPLY Again

The respiratory expert needs more discriminating information about work of breathing.

The conversational model asks:

Do you see the skin pulling in between or underneath her ribs
when she breathes?

The caregiver replies:

“Yes. I can see it pulling in a little between her ribs.”

Stage 7: ABSORB a More Consequential Observation

{
  "key": "intercostal_retractions",
  "value": true,
  "status": "caregiver_reported",
  "provenance": "conversation:turn_3"
}

Stage 8: AUTHORIZE the Recommendation

Relevant clinical escalation knowledge now contributes to the authority decision.

target:
    home_monitoring

result:
    BLOCKED


target:
    prompt_in_person_evaluation

required basis:
    respiratory distress concern

result:
    ALLOWED

The language model may now produce the caregiver-facing response.

The generation is important, but it is no longer the entire computation.

7.6 What the Caregiver Example Demonstrates

The example contains several different kinds of intelligence:

Most of the system can remain neural.

Knowledge Native programming becomes most valuable where the developer wants a particular computational relationship to remain explicit, inspectable, revisable, or mandatory.

7.7 Example Two: Maritime Trajectory Prediction

The second example illustrates a very different reason to activate specialized expertise.

Here the specialized component is not primarily checking the language model.

It performs a computation for which a general language model is not the preferred mechanism.

Suppose the current understanding contains:

subject:
    vessel-204

observed:
    trajectory_window
    timestamps
    speed
    heading
    vessel_class

required:
    future_trajectory

Declare the Predictor Capsule

id: vessel-trajectory-prediction

scope:
  domain: maritime_motion

applicable_when:
  future_motion_required: true

requires:
  - trajectory_window
  - timestamps
  - vessel_context

expertise:
  id: trajectory_predictor

result:
  type: trajectory_prediction
  establishes:
    - future_trajectory

authority:
  role: advisory

ACTIVATE

vessel-trajectory-prediction

applicable:
    yes

requirements:
    satisfied

status:
    ACTIVE

APPLY Specialized Predictive Expertise

def predict_future_track(
    understanding
):

    history = understanding.value(
        "trajectory_window"
    )

    context = understanding.value(
        "vessel_context"
    )

    prediction = trajectory_model.predict(
        history,
        context
    )

    return ExpertResult(
        result_type="trajectory_prediction",

        payload={
            "future_trajectory": prediction
        },

        epistemic_status="predicted",

        expert_id="trajectory_predictor",

        provenance=[
            "trajectory-model:v7"
        ]
    )

ABSORB

The returned track becomes knowledge, but specifically predicted knowledge.

future_trajectory

status:
    predicted

provenance:
    trajectory-model:v7

depends_on:
    trajectory_window

effect:
    collision assessment
    becomes applicable

The Runtime Continues

trajectory observations
        ↓
ACTIVATE trajectory expertise
        ↓
APPLY trajectory predictor
        ↓
ABSORB future trajectory
        ↓
ACTIVATE collision expertise
        ↓
APPLY collision assessment
        ↓
ABSORB collision risk
        ↓
ACTIVATE planning expertise
        ↓
...

The output of one expert changes the understanding, and the changed understanding determines what expertise matters next.

7.8 Example Three: Planning and Verification

A third small example makes the authority concept especially clear.

Suppose an autonomous system has:

current_state
goal
action_model
safety_specification

The runtime activates planning expertise.

ACTIVATE
    planning capsule

APPLY
    planner

RESULT
    candidate_plan

ABSORB
    candidate_plan
    status = proposed

The plan exists, but it has not earned execution authority.

The existence of a candidate plan makes verification expertise applicable.

ACTIVATE
    safety verification capsule

APPLY
    verifier

RESULT
    safety properties satisfied

ABSORB
    candidate_plan.status = verified

Only now does the runtime evaluate the execution boundary:

AUTHORIZE
    execute candidate_plan

requires:
    candidate_plan
    planning_result
    safety_verification

result:
    ALLOWED

7.9 The Same Runtime, Three Very Different Applications

The implementations are radically different.

The runtime abstraction is the same.

7.10 Why This Is Not Multi-Agent Orchestration

At first glance, the examples might look like a workflow:

LLM
  ↓
predictor
  ↓
planner
  ↓
verifier

But that is not the abstraction.

A workflow specifies that component B follows component A.

The Knowledge Runtime instead represents why B becomes relevant.

current understanding
        ↓
future trajectory missing
        ↓
trajectory expertise required
        ↓
prediction produced
        ↓
prediction absorbed
        ↓
collision question becomes meaningful
        ↓
collision expertise required

A workflow engine may still execute the calls.

KnaiTai provides the semantics that determine why those calls exist and what their outputs mean.

7.11 Why This Is Not Merely Tool Use

Modern LLM systems already call tools.

An LLM may decide:

I should use the calculator.

That is valuable.

Knowledge Native architecture supports something stronger:

For this authority boundary, this computation is required.

The requirement need not depend on whether the LLM remembers to invoke the tool.

For example:

candidate_plan exists
        ↓
governing knowledge says:
    safety verification required
        ↓
verification capsule ACTIVATE
        ↓
execution authority unavailable
until verification result is ABSORBED

The expert can still be invoked through ordinary tool infrastructure.

What changes is that its participation now has explicit runtime semantics.

7.12 Why This Is More Than Frontier AI with Context

A frontier model with rich context is a strong baseline.

Knowledge Native AI therefore cannot define its value as simply:

Give the model more knowledge.

7.13 Knowledge Capsules in the Program

The runtime examples also clarify what should and should not become a Knowledge Capsule.

These are runtime Knowledge Objects:

child has fever

respiratory status unknown

rib retractions reported

future vessel track predicted

candidate plan proposed

plan verification passed

These are good candidates for reusable Knowledge Capsules:

home-monitoring readiness

pediatric respiratory assessment

trajectory prediction expertise

collision assessment

planning expertise

maneuver safety verification

7.14 Declarative Knowledge and Runtime Binding

One of the most important properties of the programming model is separation between general knowledge and a particular case.

The declarative knowledge says:

if a pediatric patient has
intercostal retractions

then respiratory-distress
assessment becomes relevant

It does not say:

if child-17 has
intercostal retractions

then child-17 has
respiratory distress

At runtime:

general knowledge
        +
current subject
        +
current observations
        ↓
ACTIVATE
        ↓
case-specific applicability

7.15 The Trace

A Knowledge Native program should be able to expose what actually happened.

For the caregiver example:

OBSERVE
    fever
    vomiting
    responsive
    drinking

ACTIVATE
    home-monitoring-readiness

RESULT
    respiratory_status missing

AUTHORIZE
    home_monitoring → WITHHELD

APPLY
    conversational expert

ABSORB
    faster breathing

ACTIVATE
    respiratory assessment

APPLY
    conversational / clinical expert

ABSORB
    intercostal retractions

ACTIVATE
    escalation expertise

APPLY
    pathway evaluator

ABSORB
    home monitoring constrained

AUTHORIZE
    prompt evaluation → ALLOWED

For the trajectory example:

OBSERVE
    trajectory window

ACTIVATE
    trajectory predictor

APPLY
    trajectory predictor

ABSORB
    future track as prediction

ACTIVATE
    collision assessment

...

This trace is more valuable than a generated explanation because it records actual computational participation.

An LLM may subsequently turn the trace into an explanation appropriate for a caregiver, engineer, analyst, auditor, or developer.

7.16 A Slightly Richer Runtime Interface

The implementation can now expose a compact public API.

from knaitai import Runtime


runtime = Runtime()

runtime.load_capsules(
    "knowledge/"
)

case = runtime.new_case(
    subject="child-17"
)


case.observe(
    fever=True,
    vomiting=2,
    responsive=True,
    drinking=True
)


state = case.update()


print(
    state.gaps
)

print(
    state.authority(
        "home_monitoring"
    )
)

print(
    case.trace()
)

A specialized expert can be registered independently:

from knaitai.experts import PythonExpert


runtime.register_expert(

    "trajectory_predictor",

    PythonExpert(
        predict_future_track
    )
)

And a declarative capsule can bind to it:

id: vessel-trajectory-prediction

applicable_when:
  future_motion_required: true

requires:
  - trajectory_window
  - vessel_context

expertise:
  id: trajectory_predictor

result:
  type: trajectory_prediction

The application developer does not hand-wire every expert call into one procedural chain.

The runtime determines applicability from the evolving understanding.

7.17 What the Runtime Does Not Need to Build

Even this first program makes an important boundary visible.

KnaiTai does not need to implement:

• foundation-model serving;
• distributed task queues;
• agent messaging;
• workflow scheduling;
• GPU allocation;
• API retries;
• planner internals;
• trajectory-model internals;
• formal-verification algorithms;
• or user-interface rendering.

It can use existing infrastructure for all of these.

Its own abstractions remain focused:

KnowledgeObject

KnowledgeCapsule

ComputationalExpert

UnderstandingState

ACTIVATE
APPLY
ABSORB
AUTHORIZE

Dependencies

Trace

7.18 Where the Abstraction Pays Off

Suppose the trajectory predictor changes from:

kinematic predictor

to:

particle filter

and later:

trained transformer

The Knowledge Native program need not fundamentally change if all three expose the same expertise contract:

requires:
    trajectory history
    vessel context

establishes:
    future trajectory

epistemic status:
    prediction

Likewise, an LLM provider can change without rewriting the clinical authority logic.

A verifier can move from ordinary Python checks to a formal solver without changing why verification is required.

7.19 A4 as the Programming Rhythm

The first Knowledge Native program can now be summarized in four questions.

The loop repeats because ABSORB changes the understanding.

UNDERSTANDING U0

    ↓ ACTIVATE

expertise E1

    ↓ APPLY

result R1

    ↓ ABSORB

UNDERSTANDING U1

    ↓ AUTHORIZE

not enough yet

    ↓ ACTIVATE

expertise E2

    ↓ APPLY

result R2

    ↓ ABSORB

UNDERSTANDING U2

    ↓ AUTHORIZE

recommend / decide / act

This is progressive understanding expressed as computation.

7.20 The Capability Proposition

In practical terms, this supports systems that:

• use frontier neural intelligence wherever it is sufficient;
• bring specialized expertise to bear only where it adds real computational value;
• maintain an explicit evolving understanding across computations;
• represent missing knowledge rather than silently assuming it;
• preserve the difference between observations, hypotheses, predictions, plans, and verified properties;
• revise dependent understanding when upstream knowledge changes;
• require selected computation before consequential authority is granted;
• and expose a trace of what actually participated.

Knowledge Native AI does not promise perfect understanding.

It provides a programming model for making heterogeneous knowledge and expertise participate deliberately in producing better-grounded and more trustworthy system behavior.

7.21 Knowledge-Native Thinking

Do not begin by asking which model, graph, rule engine, planner, or agent framework the application requires. Begin with the evolving situation. What is known? What needs to be established? What expertise is appropriate for establishing it? What did that computation actually establish? And what recommendation, decision, or action has now earned authority?

The answer may sometimes be:

Let the foundation model handle it.

That is entirely compatible with Knowledge Native AI.

The abstraction matters when the system needs to know that a particular piece of knowledge or expertise must participate, that a result has a particular epistemic meaning, or that a consequential boundary cannot be crossed without it.

Chapter Summary

• A Knowledge Native program maintains an explicit evolving understanding rather than centering execution on a single model output.
• The minimal programming abstractions are Knowledge Objects, Knowledge Capsules, Computational Experts, an Understanding State, and the Knowledge Runtime.
• Knowledge Objects represent runtime observations, hypotheses, predictions, plans, verification results, and other case-specific knowledge.
• Knowledge Capsules declare reusable knowledge computation and should not wrap every runtime object.
• Computational Experts perform bounded computations and may be implemented by LLMs, predictors, planners, solvers, simulators, verifiers, ordinary code, services, or humans.
• The runtime is organized around four foundational semantics: ACTIVATE, APPLY, ABSORB, and AUTHORIZE.
• ACTIVATE determines what knowledge and expertise matter given the current understanding.
• Missing requirements become explicit knowledge gaps.
• APPLY invokes the appropriate computational expertise without requiring KnaiTai to own its internal implementation.
• ABSORB interprets what an expert result established and changes the understanding accordingly.
• AUTHORIZE evaluates whether the current understanding has sufficient computational grounds for a recommendation, decision, or action.
• The caregiver example shows specialized knowledge governing an authority boundary even when the foundation model may reason correctly on its own.
• The trajectory example shows specialized expertise performing a computation for which a language model is not the preferred mechanism.
• The planning example shows different expertise contributing sequentially before autonomous execution earns authority.
• Knowledge Native AI is distinct from multi-agent orchestration because its abstraction concerns why expertise participates and what its result means, not merely which component executes next.
• Knowledge Native AI is distinct from ordinary tool use because required computation need not depend on an LLM deciding to invoke a tool.
• General knowledge should be declared independently of runtime subjects and bound to concrete cases only when applicable.
• Runtime traces record actual computational participation and can support later explanation, debugging, auditing, and revision.
• The abstraction allows implementations of expertise to evolve without forcing the surrounding knowledge semantics to be rewritten.
• The core programming rhythm is ACTIVATE → APPLY → ABSORB → AUTHORIZE.

Discussion Questions

1. What makes the caregiver example Knowledge Native if a frontier model could reach the same recommendation?
2. Why should missing respiratory status be represented as a knowledge gap rather than simply left for the model to notice?
3. What makes trajectory prediction a form of computational expertise rather than merely another tool?
4. Why does a candidate plan not automatically carry execution authority?
5. What is gained by preserving the distinction among observations, hypotheses, predictions, plans, and verified properties?
6. How does ACTIVATE differ from a model router choosing among tools?
7. Why should a general capsule avoid containing identifiers such as child-17?
8. Which parts of the three examples could be delegated entirely to foundation models?
9. Which parts gain enough computational value from explicit knowledge or specialized expertise to justify representation outside the model?
10. What parts of this architecture should existing workflow or agent infrastructure handle?
11. How would changing one expert implementation affect the rest of the Knowledge Native program?
12. What should be present in a runtime trace before you would trust it as a basis for explanation?

Exercises

Exercise 7.1: Implement the Core Types

Implement KnowledgeObject, KnowledgeCapsule, ComputationalExpert, ExpertResult, and Understanding.

Exercise 7.2: Implement A4

Implement minimal versions of:

ACTIVATE
APPLY
ABSORB
AUTHORIZE

Keep specialized computation outside the runtime implementation.

Exercise 7.3: Load Declarative Knowledge

Move one capsule definition into YAML or JSON and load it into the runtime without changing the application code.

Exercise 7.4: Bind General Knowledge at Runtime

Create two subjects and demonstrate that the same capsule can become applicable to one, both, or neither depending on their current understanding.

Exercise 7.5: Integrate a Foundation Model

Use a foundation model as a Computational Expert that turns free-form user language into typed observations or proposes a natural-language question. Preserve the model result as a typed Expert Result.

Exercise 7.6: Integrate Specialized Expertise

Create a non-LLM computational expert such as a predictor, logical rule evaluator, solver, or verifier and bind it through the same expert interface.

Exercise 7.7: Model a Knowledge Gap

Create a capsule that becomes applicable but is not ready because one required item of knowledge is missing. Show how satisfying the gap changes subsequent activation.

Exercise 7.8: Preserve Epistemic Status

Create one observation, one LLM-generated hypothesis, one prediction, and one verification result. Show that ABSORB preserves their different epistemic meanings.

Exercise 7.9: Define an Authority Boundary

Choose one recommendation or action and require at least two specific pieces of knowledge or expert results before AUTHORIZE permits it.

Exercise 7.10: Replace an Expert

Replace one expert implementation while preserving the capsule declaration and runtime semantics. Identify exactly what application code did and did not need to change.

Exercise 7.11: Build a Runtime Trace

Record a complete sequence:

OBSERVE
    ↓
ACTIVATE
    ↓
APPLY
    ↓
ABSORB
    ↓
AUTHORIZE
    ↓
ACTIVATE again

For every step, record why it occurred and what changed.

Exercise 7.12: Compare Against a Frontier Model

Give the same task and background knowledge directly to a capable frontier model.

Do not assume the model will fail. Compare instead:

• the final recommendation or result;
• whether required expertise actually participated;
• whether missing knowledge was explicitly represented;
• whether result types and provenance remain distinguishable;
• whether authority conditions can be independently tested;
• and whether the resulting understanding can be revised incrementally.