Chapter 6 · Part II: Knowledge Native Architecture

The Knowledge Runtime

Knowledge capsules provide the programmable units of Knowledge Native AI. The knowledge runtime coordinates their activation, interaction, revision, inquiry, and projection so that a system can progressively improve its computational understanding rather than merely generate another answer.

6.1 From Capsules to Runtime

Chapter 5 introduced knowledge capsules as active computational units. A single capsule can represent an observation, hypothesis, guideline, uncertainty, question, prediction, human judgment, or derived conclusion. Yet useful understanding rarely emerges from one capsule in isolation.

During execution, many capsules may become relevant at once. Some support one interpretation. Others challenge it. Some constrain allowable actions. Some reveal missing knowledge. Others supersede earlier observations. A foundation model may propose a hypothesis, a graph may retrieve related entities, a rule may activate, a human may correct a fact, and a simulator may introduce a counterfactual outcome.

These activities require coordination.

Definition 6.1 (Knowledge Runtime). A knowledge runtime is the execution environment that coordinates knowledge capsules, understanding states, knowledge operations, dependencies, revision, inquiry, and projection during a Knowledge Native computation.

Knowledge Capsules
        ↓
Knowledge Runtime
        ↓
Activation
Interaction
Revision
Inquiry
Composition
Tracing
        ↓
Evolving Computational Understanding

The runtime plays a role analogous to familiar execution environments. A language runtime manages values, calls, memory, and control flow. A database engine manages queries, transactions, indexes, and views. An operating system coordinates processes, resources, and events.

A knowledge runtime manages the execution of knowledge.

Programming Principle. Knowledge capsules make knowledge programmable. The knowledge runtime makes their collective behavior executable.

6.2 What the Runtime Owns

A capsule owns its identity, semantic payload, provenance, scope, epistemic state, lifecycle, capabilities, dependencies, and contribution roles. The runtime owns coordination across capsules and tasks.

The runtime is responsible for:

registering and locating capsules;
maintaining task-relative active sets;
evaluating activation conditions;
dispatching knowledge operations;
maintaining understanding states;
recording dependencies and influence;
detecting conflicts and unresolved gaps;
scheduling the next useful computation;
propagating revisions;
creating derived capsules;
and projecting dialogue, recommendations, plans, alerts, or explanations.

Capsule responsibility	Runtime responsibility
What the knowledge represents	When and how it may participate
Local scope and capabilities	Task-relative activation and enforcement
Declared dependencies	Dependency indexing and revision propagation
Possible understanding contribution	Applying the contribution to the current understanding
Local lifecycle	Coordination of lifecycle transitions across the system

6.3 Understanding as Runtime State

A knowledge runtime does not merely maintain a collection of active capsules. It maintains an explicit understanding state.

Definition 6.2 (Runtime Understanding State). A runtime understanding state is the task-focused organization of observations, hypotheses, evidence, constraints, uncertainties, conflicts, and knowledge gaps currently held about the subject of reasoning.

Caregiver assistance.

Subject:
    child-17, current encounter

Observed:
    fever
    rash
    faster breathing

Hypotheses:
    viral illness
    respiratory infection

Active constraint:
    unresolved respiratory distress
    prevents home-monitoring recommendation

Knowledge gaps:
    respiratory rate
    responsiveness
    hydration

Current projection:
    ask targeted questions
    prepare urgent-evaluation recommendation

Operational intelligence.

Subject:
    vessel-group-12, current observation window

Observed:
    low speed
    repeated course change
    close proximity

Hypotheses:
    weather-driven maneuvering
    loitering
    possible rendezvous

Active challenge:
    severe current conditions

Knowledge gaps:
    cargo transfer evidence
    historical association
    communications

Current projection:
    analyst-facing assessment
    with ranked hypotheses

The understanding state is not a model's hidden context. It is an explicit program object maintained by the runtime.

6.4 Runtime Architecture

Sources and Users
        ↓
Constructors and Grounders
        ↓
Capsule Registry
        ↓
Activation Engine
        ↓
Knowledge Runtime
    ┌───────────────┬────────────────┐
    │               │                │
Operation Engine  Scheduler     Revision Engine
    │               │                │
    └───────────────┴────────────────┘
        ↓
Understanding State
        ↓
Projection Layer
        ↓
Dialogue, Recommendation,
Plan, Prediction, Alert, Explanation

A practical runtime may contain the following services.

Capsule Registry

Stores capsule identities, kinds, versions, locations, provenance, and dependency indexes.

Activation Engine

Determines which candidate capsules are applicable and which capabilities they may exercise in the current task.

Operation Engine

Applies support, challenge, constraint, derivation, inquiry, revision, composition, and explanation operations.

Understanding Manager

Maintains the current organized understanding and records which capsules actually influence it.

Scheduler

Selects what should happen next: apply a rule, retrieve evidence, ask a question, invoke a model, call a tool, or defer to a human.

Revision Engine

Propagates changed observations, corrected mappings, superseded policies, and invalidated hypotheses through the affected dependency region.

Trace Manager

Preserves knowledge-level execution events and paths from source information to resulting projections.

6.5 The Runtime Execution Cycle

A Knowledge Native program repeatedly executes a cycle:

1. Observe or receive information
2. Construct or retrieve capsules
3. Evaluate applicability
4. Activate permitted capsules
5. Apply knowledge operations
6. Update understanding
7. Detect conflicts and gaps
8. Select the next computation
9. Project an external response when warranted
10. Revise when new information arrives

This is not a one-pass pipeline. It is a control loop.

Current Understanding
        ↓
What matters next?
        ↓
Question, Retrieval,
Model, Rule, Tool, or Human
        ↓
New Capsule
        ↓
Revised Understanding
        ↺

Runtime Shift. The system does not merely process an input. It repeatedly decides what knowledge operation would most improve the current understanding.

6.6 Activation as Runtime Admission

Activation is the process by which an applicable capsule is admitted into the current computation.

activation = runtime.evaluate_activation(
    capsule=capsule,
    task=task,
    context=context,
    understanding=understanding
)

The runtime evaluates:

scope compatibility;
freshness;
prerequisites;
epistemic status;
authority;
task relevance;
and permitted contribution roles.

ActivationResult =
    Activate(capabilities, basis)
  | ActivateWithQualification(
        capabilities,
        basis,
        qualification
    )
  | DoNotActivate(reason)
  | CannotDetermine(missing_knowledge)

The last result is especially important. If applicability cannot be determined because knowledge is missing, the runtime may create a question capsule rather than silently treating the capsule as inactive.

6.7 From Active to Influential

Activation grants eligibility. Influence records actual participation.

Definition 6.3 (Knowledge Influence Event). A knowledge influence event records that an active capsule materially changed an understanding state, candidate set, derived capsule, or external projection.

active capsule
    ↓ contributes
understanding delta
    ↓ recorded as
influence event

An active guideline may produce no change because its premises are not satisfied. An active weather capsule may materially weaken a loitering hypothesis. An active question capsule may determine the next dialogue turn.

Distinguishing activity from influence prevents explanations from attributing a result to every object that happened to be present.

6.8 Knowledge Operations in the Runtime

The runtime mediates operations rather than allowing arbitrary capsule side effects.

runtime.apply(
    operation,
    source_capsules,
    target,
    understanding
) → OperationResult

Core operations include:

observe
support
challenge
constrain
qualify
derive
compose
reconcile
revise
request_information
explain
retire

Every operation should check capabilities, scope, state, and preconditions before execution.

def apply(operation, sources, target, state):

    require_active(sources)
    require_capability(sources, operation)
    require_scope_overlap(sources, target)
    require_preconditions(operation, state)

    result = execute(operation, sources, target, state)

    record_dependencies(result)
    record_influence(result)
    record_trace(result)

    return result

6.9 Support, Challenge, and Constraint

Three relations recur throughout runtime reasoning.

Support

A support operation increases the justification for a hypothesis, claim, action, or further investigation.

fever_observation
    supports
acute_infection_hypothesis

Challenge

A challenge operation weakens, qualifies, or disputes a capsule or relation.

severe_current_weather
    challenges
loitering_hypothesis

Constraint

A constraint operation restricts possible conclusions or actions.

respiratory_distress_guideline
    constrains
{home_monitoring,
 routine_visit,
 urgent_evaluation}

result:
{urgent_evaluation}

The runtime must preserve the distinction. Support does not automatically override a hard constraint, and a challenge does not necessarily prove the opposite conclusion.

6.10 The Reasoning Graph

Definition 6.4 (Reasoning Graph). A reasoning graph is a task-relative graph whose nodes are active, derived, question, uncertainty, conflict, and projection capsules, and whose edges represent typed reasoning relations and dependencies.

Observation Capsule
        │ supports
        ▼
Hypothesis Capsule
        │ challenged_by
        ▼
Alternative Evidence Capsule
        │ constrained_by
        ▼
Guideline Capsule
        │
        ▼
Understanding State
        │
        ▼
Recommendation Capsule

Useful edge types include:

supports
challenges
conflicts_with
constrains
qualifies
derived_from
answers
activated_by
grounded_by
validated_by
supersedes
depends_on

The graph is computational. The runtime can query all support for a hypothesis, all unresolved conflicts affecting a recommendation, all constraints excluding an action, or all dependents of a revised observation.

6.11 Conflict as Runtime State

A weak system overwrites disagreement or asks a model to select silently. A knowledge runtime represents conflict explicitly.

Definition 6.5 (Conflict Capsule). A conflict capsule represents an incompatibility, contradiction, tension, or unresolved competition among two or more capsules.

Caregiver assistance.

Capsule A:
    caregiver reports no breathing difficulty

Capsule B:
    later report indicates labored breathing

Conflict type:
    temporal observation conflict

Disposition:
    prefer newer observation,
    retain earlier state in trace

Operational intelligence.

Capsule A:
    AIS pattern supports loitering

Capsule B:
    weather explains low-speed movement

Conflict type:
    interpretation conflict

Disposition:
    retain competing hypotheses
    and request discriminating evidence

Conflict types may include direct contradiction, value disagreement, temporal conflict, scope conflict, authority conflict, rule conflict, goal conflict, and interpretation conflict.

6.12 Conflict Disposition

Definition 6.6 (Conflict Disposition). A conflict disposition is the runtime action taken in response to a detected conflict.

ResolvedByRecency
ResolvedByAuthority
ResolvedByScopeSeparation
ResolvedByNewEvidence
MergedWithQualification
Deferred
EscalatedForReview
DependentCapsuleSuspended

Not every conflict should be resolved immediately. Preserving disagreement may be more truthful than forcing one capsule to win.

6.13 Constraints and Runtime Safety

Constraints apply both to domain decisions and to the runtime itself.

Domain Constraints

do not recommend home monitoring
when respiratory distress remains unresolved

do not issue a high-confidence rendezvous alert
without sufficient independent evidence

Meta-Knowledge Constraints

a provisional capsule may not
impose an authoritative constraint

a model-generated hypothesis may not
become validated without a validation event

a final projection may not omit
an unresolved critical conflict

Definition 6.7 (Meta-Knowledge Constraint). A meta-knowledge constraint restricts how capsules may be constructed, activated, composed, revised, or allowed to influence understanding.

These constraints make the runtime safer and more predictable.

6.14 Rules as Capsules

Rules used by the runtime should themselves be represented as capsules.

RuleCapsule:
    rule_id
    premises
    conclusion_template
    scope
    priority
    exceptions
    activation_conditions
    provenance
    epistemic_state

Pediatric guideline rule.

premises:
    child
    possible respiratory distress

conclusion:
    urgent evaluation indicated

scope:
    pediatric triage

exceptions:
    none for unresolved severe distress

Behavior rule.

premises:
    repeated low-speed movement
    sustained close proximity
    no weather explanation

conclusion:
    possible rendezvous behavior

scope:
    current observation window

status:
    defeasible

Representing rules as capsules allows them to be versioned, scoped, challenged, superseded, and traced.

6.15 Defeasible Reasoning

Many conclusions are justified only until new knowledge appears.

Definition 6.8 (Defeater). A defeater is a capsule or relation that prevents, weakens, or withdraws an otherwise applicable support relation or conclusion.

rebutting defeater
    supports an opposing conclusion

undercutting defeater
    challenges the connection
    between evidence and conclusion

exception defeater
    establishes that an exception applies

Operational intelligence. Low speed and repeated course change support loitering. Severe current conditions do not necessarily support “not loitering”; instead, they undercut the inference from low speed to intentional loitering.

6.16 Assumptions as Runtime Objects

Reasoning often relies on assumptions. The runtime should represent them explicitly.

AssumptionCapsule:
    AIS coverage is sufficiently complete

status:
    provisional

supports:
    interpretation of vessel behavior

resolution:
    inspect coverage history

If an assumption is challenged, the runtime can revise dependent capsules rather than leaving hidden conditions buried inside a prompt or model call.

6.17 Knowledge Gaps and Inquiry

A reasoning step may stop because required knowledge is missing.

Definition 6.9 (Knowledge Gap Capsule). A knowledge gap capsule represents missing knowledge that blocks, weakens, or qualifies a runtime operation.

{
  "kind": "KnowledgeGapCapsule",
  "missing": "respiratory rate",
  "required_for": "severity assessment",
  "status": "open",
  "resolution": [
    "ask caregiver",
    "obtain clinical measurement"
  ]
}

The runtime may convert the gap into a question capsule:

KnowledgeGapCapsule
        ↓ formulate
QuestionCapsule
        ↓ ask
User or Tool
        ↓ answer
ObservationCapsule
        ↓ revise
Understanding State

Inquiry is therefore part of runtime control flow.

6.18 The Runtime Scheduler

Definition 6.10 (Knowledge Scheduler). A knowledge scheduler selects and orders the next useful knowledge operations over the current understanding and reasoning graph.

Possible scheduling criteria include:

risk;
information gain;
conflict urgency;
rule priority;
expected effect on understanding;
cost;
dependency readiness;
and user goal.

AgendaItem:
    operation
    source_capsules
    target
    priority
    estimated_cost
    expected_information_gain
    expected_understanding_delta

For a caregiver assistant, the scheduler may prioritize a breathing question over a detailed history question because it has greater safety impact. For operational intelligence, it may retrieve weather before vessel history because weather can quickly eliminate a competing explanation.

6.19 Tool, Model, and Human Invocation

The scheduler may invoke different computational participants:

Foundation Model
Graph Query
Rule Engine
Database
Simulator
External Tool
Human Reviewer

Each invocation should have an explicit knowledge purpose.

Invocation	Knowledge purpose
Foundation model	Interpret an observation, propose a hypothesis, formulate a question, or project an explanation
Graph query	Retrieve related entities, evidence, dependencies, or historical patterns
Rule engine	Activate conditional knowledge and derive consequences
Simulator	Test a counterfactual or projected outcome under stated assumptions
Human reviewer	Resolve ambiguity, authorize an exception, or supply expert judgment

The result of each invocation should return as one or more capsules, not disappear into untracked control flow.

6.20 Foundation Models Inside the Runtime

A foundation model is a flexible runtime component, not the owner of the complete reasoning state.

The runtime may provide the model with a structured view:

{
  "current_understanding": {...},
  "active_observations": [...],
  "competing_hypotheses": [...],
  "constraints": [...],
  "open_gaps": [...],
  "requested_operation": "formulate_next_question"
}

The model may return:

QuestionCapsuleProposal
HypothesisCapsuleProposal
MappingCapsuleProposal
ExplanationCapsuleProposal

The runtime then grounds, validates, activates, or rejects the proposal.

Architectural Principle. The foundation model contributes interpretations and projections. The runtime preserves the computational state in which those contributions acquire meaning.

6.21 Derivation and Composition

Knowledge operations often produce new capsules.

runtime.derive(
    kind,
    payload,
    inputs,
    operation,
    understanding
) → DerivedCapsule

Caregiver assistance.

Fever Capsule
    +
Respiratory-Distress Capsule
    +
Escalation Guideline Capsule
    ↓
Urgent-Evaluation Recommendation Capsule

Operational intelligence.

AIS Capsules
    +
Satellite Capsule
    +
Weather Capsule
    +
Behavior Rule Capsule
    ↓
Rendezvous Assessment Capsule

A composite understanding capsule may then organize observations, hypotheses, constraints, gaps, and projections without flattening their roles.

6.22 Incremental Revision

A long-lived runtime should update only the affected portion of the reasoning graph.

changed capsule
    ↓
dependent relations
    ↓
affected capsules
    ↓
affected understanding region
    ↓
affected projections

Caregiver assistance. A new observation of normal breathing may deactivate an escalation rule, revise severity, retire an urgent recommendation, and activate a lower-risk follow-up question.

Operational intelligence. New satellite evidence may strengthen a rendezvous hypothesis, make an earlier uncertainty capsule obsolete, and activate an analyst alert.

The runtime should preserve unaffected understanding rather than reconstructing everything after each change.

6.23 Runtime Events

Runtime behavior can be expressed through explicit events:

CapsuleRegistered
CapsuleActivated
CapsuleInfluencedUnderstanding
CapsuleChallenged
ConflictDetected
KnowledgeGapOpened
QuestionAnswered
CapsuleRevised
CapsuleSuperseded
ProjectionCreated
HumanReviewRequested

An event-driven architecture supports incremental coordination:

on QuestionAnswered(answer_capsule):
    revise_related_gap(answer_capsule)
    reevaluate_dependents(answer_capsule)
    update_understanding()
    schedule_newly_enabled_operations()

6.24 Runtime Transactions

Some knowledge updates should occur atomically.

Suppose a new observation:

supersedes an earlier capsule;
invalidates one hypothesis;
activates a guideline;
and changes a recommendation.

Exposing an intermediate state could produce contradictory projections.

Definition 6.11 (Knowledge Transaction). A knowledge transaction is an atomic group of capsule, relation, and understanding-state updates that must become visible together.

begin knowledge transaction

register new observation
supersede old observation
revise hypothesis
activate guideline
derive recommendation
record trace

commit

This connects Knowledge Native programming to familiar database concerns such as consistency, rollback, and isolation.

6.25 Runtime Invariants

A knowledge runtime should enforce invariants such as:

every active capsule has an activation basis;
every influential capsule has an influence record;
every derived capsule names its inputs;
every superseded capsule remains historically traceable;
every unresolved critical conflict qualifies or blocks final projection;
every model-produced capsule records model provenance;
and every question capsule links to the gap it is intended to resolve.

def validate_runtime(state):

    for capsule in state.active_capsules:
        assert state.has_activation_basis(capsule)

    for capsule in state.influential_capsules:
        assert state.has_influence_record(capsule)

    for capsule in state.derived_capsules:
        assert capsule.dependencies

    if state.has_critical_conflict():
        assert not state.projection.is_unqualified()

6.26 Runtime Termination and Suspension

A runtime cycle needs stopping conditions.

RuntimeOutcome =
    UnderstandingUpdated
  | ProjectionReady
  | QualifiedProjectionReady
  | NeedsMoreKnowledge
  | HumanReviewRequired
  | ConflictUnresolved
  | NoPermissibleAction
  | BudgetExhausted

Termination does not always mean that the system has a final answer. A principled runtime may stop because it needs more knowledge, cannot satisfy all constraints, or must defer to a human.

6.27 A Complete Runtime Example: Caregiver Assistance

A caregiver reports:

My daughter has a fever and rash, and now she seems to be breathing much faster.

Step 1: Construct Capsules

FeverObservationCapsule
RashObservationCapsule
PossibleRespiratoryDistressCapsule

Step 2: Ground and Activate

The runtime grounds the expressions to clinical concepts, activates pediatric guidance matching the child's age and current encounter, and restricts the model-generated respiratory interpretation to provisional use.

Step 3: Update Understanding

Current understanding:
acute febrile illness
with possible respiratory distress

Constraint:
do not recommend home monitoring
while severe breathing concern is unresolved

Step 4: Detect Knowledge Gaps

respiratory rate unknown
responsiveness unknown
skin color unknown

Step 5: Schedule Inquiry

The runtime selects the breathing question with the greatest safety impact.

QuestionCapsule:
"Is she struggling to breathe,
pulling in at the ribs,
or unable to speak normally?"

Step 6: Receive New Observation

The caregiver reports visible rib retractions.

RetractionObservationCapsule
    supports
RespiratoryDistressHypothesisCapsule

Step 7: Revise and Project

UrgentEvaluationRecommendationCapsule

basis:
    reported breathing difficulty
    visible retractions
    applicable escalation guideline

projection:
    urgent caregiver-facing recommendation
    with concise explanation

The runtime did not merely produce a response. It controlled how observations became capsules, which guideline activated, which question mattered next, how the understanding changed, and why the final recommendation was warranted.

6.28 A Complete Runtime Example: Operational Intelligence

Step 1: Active Observations

low-speed AIS movement
repeated course changes
close vessel proximity

Step 2: Model Proposal

BehaviorHypothesisCapsule:
possible rendezvous
status = provisional

Step 3: Retrieve and Activate Knowledge

weather conditions
historical vessel association
protected-zone context
behavior templates

Step 4: Challenge and Support

severe currents
    challenge intentional loitering

historical association
    supports possible rendezvous

Step 5: Detect Gap

KnowledgeGapCapsule:
cargo-transfer evidence unavailable

Step 6: Schedule Retrieval

The runtime requests satellite or sensor evidence likely to distinguish the hypotheses.

Step 7: Revise Understanding

Current understanding:
unusual vessel interaction

Most plausible:
possible rendezvous

Alternative:
weather-driven maneuvering

Unresolved:
transfer activity

Projection:
qualified analyst alert
with evidence and gaps

6.29 A Minimal Runtime API

runtime.register(capsule)
runtime.retrieve(task)
runtime.evaluate_activation(capsule, task, state)
runtime.activate(capsule, result)
runtime.contribute(capsule, understanding)
runtime.apply(operation, sources, target)
runtime.detect_conflicts(capsule)
runtime.open_gap(missing, required_for)
runtime.schedule(state)
runtime.invoke(component, purpose, inputs)
runtime.derive(kind, payload, inputs)
runtime.revise(capsule, revision)
runtime.compose(capsules)
runtime.project(kind, audience, state)
runtime.trace(target)

A small educational runtime can implement these operations using immutable dataclasses, dictionaries, adjacency lists, and append-only events.

6.30 Testing the Knowledge Runtime

Activation Tests

Does applicable knowledge activate only in the correct scope?
Does missing knowledge produce a gap rather than a false result?

Influence Tests

Is actual influence distinguished from mere activation?
Can every understanding change be traced to its contributors?

Scheduling Tests

Does the runtime prioritize high-risk questions?
Does it avoid redundant retrieval or model calls?

Revision Tests

Does a changed observation update only affected capsules?
Are superseded conclusions retired rather than overwritten?

Constraint Tests

Can model support ever bypass a hard constraint?
Does an unresolved critical conflict qualify the projection?

Trace Tests

Can the runtime reconstruct why each capsule activated?
Can it explain why a particular question was asked?
Can it distinguish source evidence from model interpretation?

6.31 Common Runtime Mistakes

Treating the Runtime as an Agent Loop

A loop of model calls and tool calls is not yet a knowledge runtime unless knowledge state, activation, dependencies, revision, and influence are explicit.

Keeping Understanding Only in the Prompt

Prompt context is transient and difficult to inspect. The current understanding should exist as an explicit program state.

Allowing the Model to Schedule Everything

A model may propose the next operation, but risk, cost, constraints, and runtime policy should also govern scheduling.

Confusing Retrieval with Activation

Retrieved capsules are candidates. The runtime must still determine applicability and permitted roles.

Confusing Activation with Influence

Presence in the active set does not mean the capsule changed the result.

Failing to Represent Questions and Gaps

When missing knowledge affects the next computation, it should be represented explicitly.

Recomputing Everything After Every Change

Use dependency indexes and incremental revision.

Generating Explanations Without Runtime Traces

An explanation should be projected from recorded participation, not invented after the fact.

6.32 The Knowledge Runtime as the Execution Model

The first six chapters now define a coherent programming progression:

Knowledge
    becomes a computational primitive

Information
    becomes computational understanding

Knowledge objects
    become knowledge capsules

Knowledge capsules
    execute within a knowledge runtime

The runtime
    progressively improves understanding

Central Thesis. A Knowledge Native program is not merely a model surrounded by tools and data. It is a runtime process in which explicit knowledge, generative models, rules, graphs, simulations, and people contribute through inspectable computational units to an evolving understanding.

The runtime is where the new programming model becomes operational. It determines which knowledge is active, which contributions matter, what uncertainty blocks progress, which computation should happen next, how revisions propagate, and what projection the current understanding justifies.

Knowledge Native Thinking

When designing execution, do not ask only:

Which agent or model should run next?

Ask:

What is the current understanding?
Which capsules are active, and which have actually become influential?
What conflict or uncertainty matters most?
What operation would most improve understanding?
Should the next step invoke a model, rule, graph, tool, simulation, or human?
What new capsule should that step produce?
How will a change propagate through dependencies?
What constraints govern the projection?
What trace will preserve the execution?

Programming Shift. Move from orchestrating model calls to orchestrating the evolution of computational understanding.

Chapter Summary

The knowledge runtime coordinates populations of knowledge capsules during execution.
The runtime owns activation, operation dispatch, understanding maintenance, scheduling, revision, and tracing.
Understanding is an explicit runtime state, not merely hidden model context.
The runtime executes a recurring cycle of observation, construction, activation, operation, inquiry, revision, and projection.
Activation makes a capsule eligible to participate; influence records actual contribution.
Support, challenge, constraint, inquiry, derivation, composition, and revision are runtime-mediated operations.
The reasoning graph represents capsules and their typed relations computationally.
Conflict capsules preserve disagreement without forcing silent resolution.
Meta-knowledge constraints govern how knowledge itself may be used.
Rules, assumptions, questions, gaps, and defeaters are first-class runtime objects.
The scheduler selects the next computation according to risk, information gain, cost, and expected understanding improvement.
Foundation models contribute interpretations and projections without owning the complete reasoning state.
Incremental revision updates only affected regions of the runtime state.
Knowledge transactions preserve consistency across related updates.
Runtime traces support debugging, audit, replay, and explanation.
The execution model of Knowledge Native AI is the programmed evolution of computational understanding.

Discussion Questions

How does a knowledge runtime differ from an agent loop?
What should a capsule own, and what should the runtime own?
Why should understanding be represented explicitly at runtime?
How does activation differ from influence?
When should a conflict remain unresolved?
What makes a question a runtime object rather than merely generated text?
How should risk and information gain affect scheduling?
What role should foundation models play inside the runtime?
Which updates should occur within a knowledge transaction?
What runtime invariants are essential for trustworthy execution?

Exercises

Exercise 6.1: Define Runtime State

Design a runtime state containing active capsules, influential capsules, the understanding state, open conflicts, open gaps, pending operations, dependencies, and trace events.

Exercise 6.2: Implement Activation

Implement an activation evaluator that returns Activate, ActivateWithQualification, DoNotActivate, or CannotDetermine.

Exercise 6.3: Record Influence

Create an influence event whenever an active capsule materially changes a hypothesis, candidate set, understanding state, or projection.

Exercise 6.4: Build a Reasoning Graph

Represent observations, hypotheses, guidelines, questions, uncertainties, and recommendations as capsules connected by typed relations.

Exercise 6.5: Implement a Scheduler

Rank pending operations by risk, expected information gain, cost, and expected effect on understanding.

Exercise 6.6: Integrate a Foundation Model

Provide a model with a structured runtime view and require it to return a provisional question, hypothesis, mapping, or explanation capsule.

Exercise 6.7: Program a Knowledge Transaction

Atomically supersede one observation, revise a hypothesis, activate a constraint, derive a recommendation, and record the trace.

Exercise 6.8: Implement Incremental Revision

Revise one source capsule and update only the affected dependencies, understanding region, and projections.

Exercise 6.9: Reproduce the Caregiver Runtime

Implement the execution cycle from Section 6.27, including knowledge-gap creation, question scheduling, answer ingestion, revision, and recommendation projection.

Exercise 6.10: Reproduce the Operational Runtime

Implement competing behavioral hypotheses, weather-based challenge, evidence retrieval, and qualified analyst projection.