Chapter 6 · Part II: Knowledge Native Architecture

The Knowledge Runtime

Knowledge Capsules declare how knowledge and computational expertise may participate in a Knowledge Native program. The Knowledge Runtime makes those declarations operational. It maintains the system's evolving understanding, determines what knowledge and expertise matter now, absorbs what computations establish, and governs when recommendations, decisions, or actions have earned computational authority.

6.1 From Capsules to Runtime

Chapter 5 introduced the Knowledge Capsule as a declarative boundary connecting knowledge, applicability, requirements, computational expertise, result semantics, authority, and provenance.

A capsule by itself does not execute an intelligent system.

At runtime, a system must continuously connect:

what is currently known;
what remains unresolved;
what knowledge is now applicable;
what computational expertise should participate;
what that computation establishes;
how the understanding changes;
and what authority follows.

Definition 6.1 (Knowledge Runtime). A Knowledge Runtime is the execution environment that maintains evolving computational understanding and applies the semantics of ACTIVATE, APPLY, ABSORB, and AUTHORIZE across heterogeneous knowledge and computational expertise.

Knowledge + Current State
          ↓
       ACTIVATE
          ↓
Applicable / Required Expertise
          ↓
        APPLY
          ↓
     Expert Result
          ↓
       ABSORB
          ↓
Revised Understanding
          ↓
      AUTHORIZE
          ↓
Continue / Recommend /
Decide / Act
          ↓
          ↺

The Knowledge Runtime is the semantic execution model of Knowledge Native AI.

6.2 What the Runtime Owns

The runtime should own only those responsibilities that are essential to Knowledge Native semantics.

It should not become a general workflow engine, agent framework, model router, distributed scheduler, or tool bus.

Knowledge Runtime owns	Existing infrastructure may own
Current understanding state	Databases, queues, memory stores
Applicability of knowledge and expertise	Search, indexing, retrieval infrastructure
Requirements and missing knowledge	UI, messaging, sensor access, external APIs
Meaning of expert results	Model serving and tool execution
Dependency and revision semantics	Persistence implementation
Authority conditions	Business workflow execution
Knowledge-level trace	Logs, telemetry, observability infrastructure
A4 semantics	Scheduling, retries, parallelism, agent coordination

Runtime Boundary.
KnaiTai determines why expertise should participate and what its result means. Existing execution infrastructure may determine how that expertise is called.

6.3 Understanding as Runtime State

The runtime does not merely maintain an active set of capsules.

Its central state is the system's current computational understanding.

Definition 6.2 (Understanding State). An Understanding State is the task-focused structured representation of what is currently observed, inferred, predicted, proposed, assumed, constrained, verified, unresolved, or authorized about the subject of reasoning.

An understanding state may contain:

observations;
hypotheses;
predictions;
candidate plans;
verified properties;
constraints;
assumptions;
knowledge gaps;
expert results;
dependencies;
and authority status.

Caregiver assistance.

subject:
    child-17

observed:
    fever
    vomiting
    responsive
    drinking fluids

unknown:
    respiratory_status

proposed:
    home_monitoring

authority:
    home_monitoring = NOT_YET_ALLOWED

Autonomous navigation.

subject:
    vessel-204

observed:
    recent trajectory
    current heading
    current speed

predicted:
    none yet

required:
    future trajectory

authority:
    maneuver execution = WITHHELD

The understanding state is not the prompt.
It is an explicit program object maintained independently of any one model invocation.

6.4 The Runtime Architecture

                 APPLICATION
                      │
                      ▼
             KNOWLEDGE RUNTIME
                      │
      ┌───────────────┼────────────────┐
      │               │                │
      ▼               ▼                ▼
 Understanding    Capsule / Expert   Trace +
    State            Registry       Dependencies
      │               │                │
      └───────────────┼────────────────┘
                      │
             ACTIVATE / APPLY
                      │
                      ▼
           COMPUTATIONAL EXPERTISE
                      │
     ┌────────┬────────┼────────┬────────┐
     ▼        ▼        ▼        ▼        ▼
    LLM    Predictor Planner  Solver  Verifier
     │        │        │        │        │
     └────────┴────────┼────────┴────────┘
                      │
               Expert Results
                      │
                      ▼
                   ABSORB
                      │
                      ▼
              Updated Understanding
                      │
                      ▼
                  AUTHORIZE

The runtime may rely on supporting services:

a capsule registry;
an expert registry;
a knowledge store;
a dependency index;
a trace store;
and adapters to external execution infrastructure.

These are implementation services. They should not be confused with additional foundational runtime operators.

6.5 The A4 Runtime Cycle

The Knowledge Runtime repeatedly performs four semantic operations.

ACTIVATE → APPLY → ABSORB → AUTHORIZE

ACTIVATE

Determine what knowledge and computational expertise matter given the current understanding.

active = runtime.activate(
    understanding
)

APPLY

Put the relevant expertise to work when its requirements are satisfied.

results = runtime.apply(
    active,
    understanding
)

ABSORB

Interpret what each result established and change the understanding accordingly.

understanding = runtime.absorb(
    understanding,
    results
)

AUTHORIZE

Determine what recommendations, decisions, or actions the revised understanding now permits.

authority = runtime.authorize(
    understanding
)

A simplified execution loop is:

while task.active:

    active = ACTIVATE(
        understanding
    )

    results = APPLY(
        active,
        understanding
    )

    understanding = ABSORB(
        understanding,
        results
    )

    authority = AUTHORIZE(
        understanding
    )

    if authority.permits_outcome():
        emit_or_act()

    else:
        continue

A4 describes runtime semantics, not a mandatory physical execution sequence.
A real implementation may batch, parallelize, defer, or externally orchestrate computations.

6.6 ACTIVATE: What Matters Now?

Activation evaluates the relationship between the current understanding and available capsules or expertise.

Definition 6.3 (Activation). Activation is the determination that knowledge or computational expertise is relevant, applicable, or required in the current understanding.

Activation may consider:

scope;
current state;
entity type;
task or goal;
preconditions;
available evidence;
knowledge gaps;
and authority requirements.

A compact activation result might be:

ActivationResult

    ACTIVE
    INACTIVE
    NOT_READY
    OUT_OF_SCOPE

For example:

capsule:
    respiratory_assessment

applicable:
    true

requires:
    work_of_breathing

current:
    work_of_breathing = UNKNOWN

activation:
    NOT_READY

Applicable is not the same as executable.
ACTIVATE may reveal that relevant expertise cannot yet run because required knowledge is missing.

6.7 Knowledge Gaps Become Runtime State

Missing knowledge should not be treated merely as a null field.

Definition 6.4 (Knowledge Gap). A knowledge gap is an explicitly represented absence whose resolution may change applicability, understanding, or authority.

A gap may record:

missing:
    respiratory_status

required_for:
    home_monitoring_authorization

possible_resolution:
    caregiver_question

Or:

missing:
    future_trajectory

required_for:
    collision_assessment

possible_resolution:
    trajectory_predictor

The runtime need not itself decide how a question is rendered, how a sensor is queried, or how an API is called.

It needs to represent that the missing knowledge is computationally consequential.

6.8 APPLY: Computational Expertise Enters the Runtime

APPLY is deliberately general.

The Knowledge Runtime does not need separate top-level operators for prediction, planning, deduction, simulation, optimization, or verification.

Those are different forms of computational expertise.

APPLY(llm_expert)
    → clinical interpretation

APPLY(trajectory_predictor)
    → future trajectory

APPLY(planner)
    → candidate plan

APPLY(constraint_solver)
    → admissibility result

APPLY(simulator)
    → projected physical state

APPLY(formal_verifier)
    → verified property

APPLY is the abstraction boundary over heterogeneous computation.

The underlying implementation may be:

Python;
a foundation-model API;
a local model;
a planner;
a theorem prover;
a solver;
a simulation package;
a database query;
an external service;
or a human task.

6.9 Runtime Does Not Mean Scheduler

The runtime may determine that an expert should be applied.

It need not own the entire mechanics of making that computation happen.

For example:

Knowledge Runtime:

    trajectory predictor REQUIRED

Execution layer:

    locate service
    authenticate
    call endpoint
    retry if needed
    allocate GPU
    enforce timeout
    return result

This allows KnaiTai to complement:

LangGraph;
Temporal;
Airflow;
ROS;
agent frameworks;
MCP-based tool systems;
Kubernetes services;
or ordinary application code.

The runtime may request computation without becoming the universal orchestrator of computation.

6.10 Expert Results Are Typed Computational Claims

A result returning from APPLY should not be interpreted merely as arbitrary output.

A useful expert result contains enough semantics for ABSORB to interpret it correctly.

ExpertResult

    expert_id
    result_type
    payload
    epistemic_status
    provenance
    assumptions
    dependencies
    validity_scope

Examples:

result_type:
    hypothesis

epistemic_status:
    proposed

result_type:
    trajectory_prediction

epistemic_status:
    predicted

result_type:
    verification_result

epistemic_status:
    verified

The runtime should not collapse these into equivalent facts.

6.11 ABSORB: Computation Changes Understanding

Definition 6.5 (Absorption). Absorption is the incorporation of a computational result into the evolving understanding according to the result's epistemic status, provenance, dependencies, scope, and computational meaning.

ABSORB may:

add a new observation;
introduce a hypothesis;
strengthen or weaken an existing hypothesis;
replace a stale prediction;
introduce a candidate plan;
establish a verified property;
invalidate an existing conclusion;
open a new knowledge gap;
or make different expertise applicable.

Prediction.

APPLY:
    trajectory_predictor

RESULT:
    crossing_probability = 0.87

ABSORB:

    future_trajectory = prediction-41

    potential_collision =
        newly_supported

    collision_assessment =
        newly_applicable

Verification.

APPLY:
    plan_verifier

RESULT:
    constraint C7 violated

ABSORB:

    candidate_plan.status =
        invalid

    execution_candidate =
        removed

    replanning =
        newly_applicable

ABSORB means understanding changed.
It is not simply another result being collected.

6.12 Dependencies Make Understanding Revisable

Absorption should preserve dependencies between inputs, computations, and resulting knowledge.

trajectory observations
        ↓
trajectory predictor
        ↓
trajectory prediction
        ↓
collision assessment
        ↓
candidate maneuver
        ↓
verification
        ↓
execution authority

If the upstream trajectory observations change, the runtime can identify which downstream results are affected.

Definition 6.6 (Runtime Dependency). A runtime dependency records that the status, validity, interpretation, or authority of one result depends upon particular knowledge or prior computation.

Dependencies may include:

derived_from
depends_on
supersedes
verified_by
constrained_by
supported_by
challenged_by

These are relations in the runtime state, not additional foundational operators.

6.13 Incremental Revision

Knowledge Native computation should normally revise only what has been affected.

Caregiver assistance.

old observation:
    no breathing difficulty

new observation:
    rib retractions present

ABSORB new observation

affected:
    respiratory assessment
    disposition assessment
    authority status

unaffected:
    unrelated observations

Trajectory prediction.

new trajectory observations
        ↓
invalidate old prediction
        ↓
reapply predictor
        ↓
replace prediction
        ↓
reconsider collision estimate
        ↓
reconsider dependent plan
        ↓
reconsider authority

This resembles incremental view maintenance, build dependency systems, spreadsheets, and dataflow execution.

Progressive understanding should be incremental computation, not repeated reconstruction from scratch.

6.14 Conflict Is Part of Understanding

A Knowledge Runtime should not force every disagreement into immediate resolution.

Conflicting knowledge or expert results may coexist.

Observation A:
    no breathing difficulty reported

Observation B:
    later rib retractions reported

Or:

Predictor A:
    low collision risk

Predictor B:
    high collision risk

The runtime can represent:

the conflicting objects;
their provenance;
their times;
their scopes;
their dependencies;
and whether the conflict blocks authorization.

Conflict is runtime state, not necessarily runtime failure.

6.15 Support, Challenge, Constraint, Prediction, and Verification

These concepts remain important, but they should not be elevated into separate top-level runtime operators.

They are better understood as result semantics or relations created during APPLY and ABSORB.

LLM result
    PROPOSES hypothesis

observation
    SUPPORTS hypothesis

weather evidence
    CHALLENGES hypothesis

clinical guideline
    CONSTRAINS recommendation

predictor
    PREDICTS future state

verifier
    VERIFIES property

A4 remains the stable runtime abstraction:

ACTIVATE
APPLY
ABSORB
AUTHORIZE

Keep the operator set small and let expert/result semantics carry the richness.

6.16 AUTHORIZE: Governing Computational Authority

Definition 6.7 (Authorization). Authorization evaluates whether the current understanding satisfies the conditions required for a recommendation, decision, or action to cross a defined computational authority boundary.

AUTHORIZE may ask:

Is required evidence present?
Has mandatory expertise participated?
Are required constraints satisfied?
Has verification succeeded?
Are any blocking conflicts unresolved?
Is required human approval present?

For example:

target:
    home_monitoring

requires:
    responsiveness_assessed
    hydration_assessed
    respiratory_status_assessed
    no_active_escalation_condition

result:
    DENIED

Or:

target:
    execute_maneuver

requires:
    current trajectory prediction
    feasible plan
    collision constraint passed
    dynamics verification passed

result:
    ALLOWED

Confidence and authority are different.
A high-confidence result may lack required assurance. A system may also act under uncertainty when governing knowledge explicitly permits it.

6.17 Computational Assurance

Authorization often depends on accumulated computational assurance.

Definition 6.8 (Computational Assurance). Computational assurance is the body of evidence, expert results, checks, constraints, and verification that provides grounds for granting computational authority.

Assurance may be very light:

LLM recommendation
        ↓
AUTHORIZE advisory response

Or substantial:

perception
    +
prediction
    +
planning
    +
constraint checking
    +
verification
        ↓
AUTHORIZE autonomous execution

Trust is earned.
In Knowledge Native AI, the required trust can be earned computationally through the appropriate participation of knowledge and expertise.

6.18 Authority Is Application-Specific

KnaiTai should not dictate one universal hierarchy of authority.

Different applications may define different boundaries.

Application	Possible authority boundary
Consumer assistant	Authority to provide an advisory response
Caregiver assistant	Authority to recommend home monitoring or escalation
Clinical decision support	Authority to present a treatment recommendation to a clinician
Operational intelligence	Authority to promote an assessment or alert
Engineering system	Authority to accept a design candidate
Autonomous system	Authority to execute a physical action

The runtime provides the abstraction for evaluating authority. Domain knowledge defines what must be satisfied.

6.19 Foundation Models Inside the Runtime

Foundation models may remain the dominant computational expert in many applications.

A model may:

interpret natural-language observations;
maintain conversational context;
propose hypotheses;
summarize evidence;
formulate questions;
generate candidate plans;
or produce user-facing explanations.

The runtime may provide structured context:

{
  "understanding": {...},

  "open_gaps": [...],

  "active_constraints": [...],

  "requested_capability":
      "clinical_interpretation"
}

The model returns a typed result:

{
  "result_type":
      "clinical_interpretation",

  "epistemic_status":
      "proposed",

  "payload":
      {...}
}

ABSORB then incorporates the result according to its declared semantics.

The model can reason broadly without owning the complete semantics of the running system.

6.20 Specialized Experts Inside the Same Runtime

The same runtime can apply expertise that is fundamentally different from language reasoning.

Trajectory Predictor
    input:
        trajectory history

    establishes:
        predicted future motion


Planner
    input:
        current state
        goal
        action model

    establishes:
        candidate plan


Formal Verifier
    input:
        candidate
        specification

    establishes:
        verified / violated


Simulator
    input:
        state
        parameters
        candidate action

    establishes:
        projected physical outcome

KnaiTai does not need a different runtime architecture for each one.

They all participate through the same semantic cycle.

6.21 Human Expertise Inside the Runtime

Humans may also serve as computational experts.

A runtime may determine:

expertise_required:
    specialist_review

reason:
    unresolved high-impact ambiguity

Existing workflow infrastructure can route the case to a human.

The returned judgment should preserve:

identity or role;
time;
scope;
what was reviewed;
what was established;
and authority.

A human is therefore not an exception to the architecture.

Human expertise is another possible participant whose results may carry distinctive authority.

6.22 The Runtime Trace

Definition 6.9 (Knowledge Runtime Trace). A Knowledge Runtime Trace is the structured record of knowledge activation, expert application, absorbed results, dependencies, revisions, and authority decisions that materially affected an outcome.

For example:

ACTIVATE
    home-monitoring-readiness

RESULT
    respiratory_status missing

AUTHORIZE
    home_monitoring
    → DENIED

ACTIVATE
    respiratory-assessment

APPLY
    clinical conversation expert

RESULT
    rib_retractions observed

ABSORB
    respiratory_distress concern

ACTIVATE
    escalation guidance

APPLY
    pathway evaluator

ABSORB
    home_monitoring constrained

AUTHORIZE
    prompt evaluation
    → ALLOWED

This differs from a generated rationale.

The trace records what actually happened.

A natural-language explanation can later be projected from it.

6.23 Runtime Events

An implementation may expose meaningful runtime events.

Keep these as events, not as new conceptual operators.

KnowledgeObserved
CapsuleActivated
ExpertApplied
ExpertResultProduced
UnderstandingChanged
KnowledgeGapOpened
ResultSuperseded
AuthorityGranted
AuthorityWithheld
HumanReviewRequired

Events support:

debugging;
observability;
UI updates;
persistence;
incremental processing;
and audit.

6.24 Runtime Transactions

Some updates should become visible atomically.

Suppose a new observation:

supersedes an earlier observation;
invalidates an existing prediction;
changes a hypothesis;
and removes authority from an action.

An intermediate state could be inconsistent.

Definition 6.10 (Knowledge Transaction). A knowledge transaction is an atomic set of related understanding, dependency, trace, and authority updates that become visible together.

begin

ABSORB new observation

supersede old observation

invalidate dependent prediction

withdraw execution authority

record trace

commit

This connects Knowledge Native runtime design to familiar database concerns such as consistency and atomicity.

6.25 Runtime Invariants

A runtime should enforce a small number of strong invariants.

Every expert result has identifiable provenance.
Every absorbed result preserves its epistemic status.
Every material understanding change has a trace basis.
Every derived or revised result preserves relevant dependencies.
No superseded result silently remains authoritative.
Required expertise cannot be skipped when evaluating an authority boundary.
Missing mandatory knowledge cannot be silently treated as known.
Authorization cannot exceed the authority established by the current understanding.

Runtime invariants protect semantics, not merely data integrity.

6.26 Runtime Outcomes

A Knowledge Native computation does not always end with an answer.

Possible outcomes include:

OUTPUT_AUTHORIZED

MORE_KNOWLEDGE_REQUIRED

EXPERTISE_REQUIRED

HUMAN_REVIEW_REQUIRED

CONFLICT_UNRESOLVED

ACTION_BLOCKED

NO_PERMISSIBLE_ACTION

BUDGET_OR_RESOURCE_LIMIT

A principled runtime can therefore stop because it does not yet have sufficient computational grounds to proceed.

6.27 Complete Example: Caregiver Assistance

Consider a caregiver asking:

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

Current Understanding

subject:
    child-17

observed:
    fever
    vomiting
    responsive
    drinking

requested:
    home_monitoring

unknown:
    respiratory_status

ACTIVATE

The home-monitoring readiness capsule applies.

requires:
    responsiveness
    hydration_status
    respiratory_status

AUTHORIZE

home_monitoring:
    NOT_YET_ALLOWED

missing:
    respiratory_status

APPLY Conversational Expertise

The LLM or conversational clinical expert asks about breathing.

The caregiver replies:

She's breathing faster than normal.

ABSORB

observation:
    increased_breathing

effect:
    respiratory assessment
    becomes applicable

APPLY Respiratory Assessment

The system asks about work of breathing.

The caregiver replies:

Yes, I can see the skin pulling in between her ribs.

ABSORB

observation:
    intercostal_retractions

understanding:
    respiratory_distress_concern
        supported

ACTIVATE

clinical escalation knowledge

APPLY

pathway evaluator

result:
    home_monitoring constrained
    prompt evaluation indicated

ABSORB + AUTHORIZE

home_monitoring:
    BLOCKED

prompt_evaluation:
    RECOMMENDATION_AUTHORIZED

The foundation model may independently reason to exactly the same conclusion.
The Knowledge Runtime matters because the application explicitly required selected clinical expertise to participate before granting authority to the recommendation.

6.28 Complete Example: Trajectory Prediction

Consider a moving vessel for which future position has become consequential.

Current Understanding

observed:
    trajectory_window
    timestamps
    heading
    speed

required:
    future_trajectory

ACTIVATE

trajectory_prediction capsule:
    ACTIVE

requirements:
    satisfied

APPLY

trajectory_predictor(
    trajectory_window,
    vessel_context
)

→ predicted_future_track

ABSORB

predicted_future_track

type:
    prediction

effect:
    collision assessment
    now applicable

ACTIVATE Again

collision_assessment expertise

The runtime is not using specialized expertise merely as a check on an LLM.

The specialized predictor is performing the computation appropriate to the problem.

6.29 Complete Example: Planning, Verification, and Action

Consider an autonomous system with a goal requiring a multi-step plan.

ACTIVATE

planning expertise:
    REQUIRED

APPLY

planner(
    current_state,
    goal,
    action_model
)

→ candidate_plan

ABSORB

candidate_plan

status:
    proposed

authority:
    not executable

ACTIVATE

safety_verification:
    REQUIRED

APPLY

verifier(candidate_plan)

→ safety constraints satisfied

ABSORB

candidate_plan:
    verified

AUTHORIZE

execute candidate_plan

→ ALLOWED

This is the same Knowledge Runtime pattern as the caregiver example, despite radically different underlying computation.

6.30 A Minimal Runtime API

The public API should remain small.

from knaitai import Runtime


runtime = Runtime()

runtime.load_capsules(
    "knowledge/"
)

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

case.observe(
    fever=True
)

state = case.update()

Internally, the runtime may expose:

runtime.activate(state)

runtime.apply(
    active,
    state
)

runtime.absorb(
    state,
    results
)

runtime.authorize(
    state,
    target
)

runtime.trace(
    target
)

Additional implementation services may exist, but the public programming model should remain centered on the core abstractions.

6.31 A Minimal Internal Architecture

runtime.py

    Runtime

understanding.py

    UnderstandingState

capsule.py

    KnowledgeCapsule

knowledge.py

    KnowledgeObject

experts.py

    ComputationalExpert
    PythonExpert
    ExternalExpert

registry.py

    CapsuleRegistry
    ExpertRegistry

authority.py

    AuthorityResult

trace.py

    RuntimeTrace

dependencies.py

    DependencyGraph

A v0.1 implementation can remain entirely in ordinary Python with Pydantic models and in-memory collections.

More sophisticated persistence, graph storage, distributed execution, agent frameworks, and external model services can be added later without changing the central runtime semantics.

6.32 Testing the Knowledge Runtime

ACTIVATE Tests

Does applicable expertise activate in the correct situation?
Does out-of-scope expertise remain inactive?
Are missing requirements represented explicitly?

APPLY Tests

Are the correct inputs bound to the expert?
Does the runtime preserve expert identity and provenance?
Can multiple expert implementations participate through the same abstraction?

ABSORB Tests

Does a prediction remain a prediction?
Does a verification result receive stronger epistemic status where appropriate?
Are dependencies preserved?
Are affected conclusions revised without disturbing unrelated state?

AUTHORIZE Tests

Is authority withheld when required knowledge is missing?
Can mandatory verification prevent execution?
Can advisory results contribute without becoming authoritative?

Trace Tests

Can the runtime reconstruct why expertise activated?
Can it identify which expert produced each consequential result?
Can it explain why authority was granted or withheld?

6.33 Common Runtime Mistakes

Turning the Runtime into an Agent Framework

Agent messaging, tool coordination, retries, routing, and workflow execution are useful infrastructure but not the core Knowledge Runtime abstraction.

Turning the Runtime into a Scheduler

The runtime may determine that expertise is required. It need not own all mechanisms for deciding which worker, process, service, or agent executes it.

Keeping Understanding Only in Prompt Context

Prompt context may inform an LLM, but the Knowledge Runtime requires explicit understanding state for dependency tracking, revision, and authority.

Reintroducing Too Many Operators

Keep the semantic core at:

ACTIVATE
APPLY
ABSORB
AUTHORIZE

Support, challenge, prediction, planning, verification, constraint checking, and similar concepts belong in expert or result semantics.

Making Every Result a Capsule

Runtime observations and expert results are often better represented as Knowledge Objects. Capsules are reusable declarations of knowledge computation.

Giving the LLM Too Little Responsibility

Do not reproduce with symbolic machinery what a strong foundation model already handles reliably unless the explicit representation provides real computational leverage.

Giving the LLM Too Much Authority

Conversely, important authority boundaries should not depend solely on whether the model happened to remember or apply a critical requirement.

Confusing Confidence with Assurance

A confidence score does not establish that required expertise participated or that mandatory constraints were satisfied.

Recomputing Everything

Use dependencies and incremental revision.

Generating Explanations Without Trace

A fluent rationale is not a substitute for the runtime record of actual computational participation.

6.34 The Knowledge Runtime as the Execution Model

The architecture developed so far can now be summarized cleanly:

KNOWLEDGE

    what is known

        ↓

KNOWLEDGE CAPSULES

    declare how reusable
    knowledge and expertise
    may participate

        ↓

KNOWLEDGE RUNTIME

    ACTIVATE
    APPLY
    ABSORB
    AUTHORIZE

        ↓

COMPUTATIONAL EXPERTISE

    LLM
    predictor
    planner
    solver
    simulator
    verifier
    algorithm
    human

        ↓

EVOLVING UNDERSTANDING

        ↓

COMPUTATIONAL ASSURANCE

        ↓

COMPUTATIONAL AUTHORITY

        ↓

RECOMMEND
DECIDE
ACT

Central Thesis.
The Knowledge Runtime makes heterogeneous knowledge computation programmable by maintaining an evolving understanding and governing how computational expertise participates in earning authority for recommendations, decisions, and actions.

This is not merely a model surrounded by tools.

Nor is it a collection of cooperating agents.

It is an abstraction and runtime for knowledge-driven participation of heterogeneous computational expertise.

Knowledge Native Thinking

When designing runtime behavior, do not begin only with:

What component should run next?

Ask:

What is currently understood?
What knowledge matters now?
What remains unresolved?
What computational expertise is applicable?
What requirements must be satisfied before that expertise can run?
What does the returned result actually establish?
How should the result change the understanding?
What dependencies must be preserved?
What expertise becomes applicable after that change?
What assurance is required at the current authority boundary?
What may the system now recommend, decide, or do?

Programming Shift.
Move from orchestrating components to programming the semantics by which knowledge activates expertise, expertise changes understanding, and understanding earns computational authority.

Chapter Summary

The Knowledge Runtime is the semantic execution environment of Knowledge Native AI.
Its central state is an explicit evolving understanding rather than a model's hidden prompt context.
The runtime is centered on four foundational operations: ACTIVATE, APPLY, ABSORB, and AUTHORIZE.
ACTIVATE determines what knowledge and expertise matter in the current state.
Knowledge gaps may make expertise applicable but not yet executable.
APPLY provides the common abstraction through which heterogeneous computational expertise participates.
Existing orchestration infrastructure may perform the physical invocation of models, tools, services, agents, and humans.
Expert results must preserve result type, epistemic status, provenance, assumptions, dependencies, and scope.
ABSORB converts computational results into changes in the evolving understanding.
Dependencies support incremental revision when observations, assumptions, or expert results change.
Support, challenge, constraint, prediction, planning, and verification are result semantics rather than foundational runtime operators.
AUTHORIZE governs whether the current understanding permits a recommendation, decision, or action.
Computational assurance records the grounds through which computational authority is earned.
Authority is application-specific and may range from advisory response to autonomous execution.
Foundation models, predictors, planners, solvers, simulators, verifiers, conventional algorithms, and humans can participate through the same runtime abstraction.
Runtime traces record actual computational participation rather than post-hoc rationale.
Knowledge transactions and runtime invariants help preserve semantic consistency.
The Knowledge Runtime should complement rather than replace workflow, tool, model-serving, and multi-agent infrastructure.

Discussion Questions

What responsibilities must belong to the Knowledge Runtime, and which should remain in existing orchestration infrastructure?
Why should understanding exist outside a model's prompt context?
How does ACTIVATE differ from tool selection or routing?
Why is applicability different from execution readiness?
What must an Expert Result contain for ABSORB to interpret it correctly?
Why should prediction, planning, verification, and constraint checking remain below APPLY rather than become separate runtime operators?
How should dependency tracking support incremental revision?
When should conflicting results remain unresolved rather than be collapsed into one answer?
What is the difference between confidence, computational assurance, and computational authority?
How should the amount of required assurance change as a system moves from recommendation to autonomous action?
What role should a foundation model play inside a Knowledge Runtime?
How can a runtime leverage multi-agent or workflow infrastructure without becoming an orchestration framework itself?

Exercises

Exercise 6.1: Design an Understanding State

Create an understanding state containing observations, one hypothesis, one prediction, one knowledge gap, one candidate action, and one authority status.

Exercise 6.2: Implement ACTIVATE

Write a function that evaluates several capsules against an understanding state and returns ACTIVE, INACTIVE, NOT_READY, or OUT_OF_SCOPE.

Exercise 6.3: Integrate Two Different Experts

Create one Python expert and one mock external expert. Make both participate through the same APPLY interface.

Exercise 6.4: Implement Expert Results

Represent one LLM hypothesis, one predictor output, and one verification result using a common structured result model while preserving their different epistemic meanings.

Exercise 6.5: Implement ABSORB

Create an ABSORB function that accepts an expert result, updates the understanding, preserves provenance and dependencies, and activates a new piece of expertise when appropriate.

Exercise 6.6: Propagate a Revision

Change one source observation and invalidate only the dependent prediction, hypothesis, plan, or authority state rather than recomputing the complete understanding.

Exercise 6.7: Implement AUTHORIZE

Define one authority boundary requiring multiple pieces of knowledge or expert results. Show that authority is withheld until all mandatory conditions are satisfied.

Exercise 6.8: Separate Runtime from Orchestration

Design a system using a Knowledge Runtime plus an external workflow framework. Identify exactly what each layer owns.

Exercise 6.9: Create a Runtime Trace

Record one complete sequence:

ACTIVATE
    ↓
APPLY
    ↓
ABSORB
    ↓
AUTHORIZE
    ↓
ACTIVATE again

Include the knowledge basis, expert identity, result semantics, understanding change, and authority decision.

Exercise 6.10: Reproduce the Three Runtime Patterns

Implement small versions of:

a caregiver recommendation requiring selected clinical expertise;
a trajectory prediction requiring specialized predictive expertise;
and a planning problem requiring verification before execution authority.

Use the same A4 runtime abstraction for all three.