From Information to Computational Understanding

A Knowledge Native architecture turns heterogeneous information into an evolving computational understanding and uses that understanding to determine what knowledge and computational expertise should participate next. The architecture is therefore not simply a pipeline into a model. It is a runtime in which knowledge is constructed, activated, applied through appropriate expertise, absorbed back into understanding, and used to govern what the system may recommend, decide, or do.

4.1 Architecture Begins With What Must Be Established

A conventional AI architecture is often represented as:

input
  ↓
model
  ↓
output

Modern agent architectures add tools and workflows:

input
  ↓
model / agent
  ↓
tools / APIs / other agents
  ↓
output

Both abstractions are useful. Neither captures the central architectural problem addressed by Knowledge Native AI.

The important question is not only:

What component should execute next?

It is:

Given what the system currently understands, what must now be established, what knowledge matters, what computational expertise is appropriate, and what authority should follow from its result?

A Knowledge Native architecture therefore centers on an evolving understanding:

Sources / Observations / Requests
              ↓
      KNOWLEDGE CONSTRUCTION
              ↓
       CURRENT UNDERSTANDING
              ↓
           ACTIVATE
              ↓
 What knowledge and expertise
          matter now?
              ↓
            APPLY
              ↓
   Computational Expertise
              ↓
            RESULT
              ↓
           ABSORB
              ↓
     Revised Understanding
              ↓
          AUTHORIZE
              ↓
 Continue / Recommend /
      Decide / Act
              ↓
              ↺

4.2 Information, Knowledge, and Expertise Are Different Things

A source provides information in some physical or logical representation.

A database may provide a row. A sensor provides a measurement. A document provides prose. A foundation model provides an interpretation. A simulator provides a projected outcome. A planner provides a plan. A person provides an observation or judgment.

These are not interchangeable.

Knowledge Native architecture distinguishes three related layers:

Thus:

trajectory observations
        =
knowledge

trajectory prediction model
        +
ability to compute future motion
        =
computational expertise

Similarly:

actions + preconditions + effects
        =
planning knowledge

planner + search
        =
planning expertise

And:

clinical guideline
        =
knowledge

pathway evaluator
        =
computational expertise

A foundation model contains learned knowledge and also supplies broad computational expertise in interpretation, synthesis, reasoning, and generation.

4.3 Sources Produce Material for Knowledge Construction

Knowledge in a real system may originate from many places.

Structured Sources

Relational databases, graphs, RDF stores, ontologies, typed APIs, clinical terminologies, symbol tables, and configuration stores already provide explicit structure.

Semi-Structured Sources

JSON, XML, YAML, event logs, telemetry messages, and typed envelopes preserve partial structure but often require mapping into the application's concepts.

Unstructured Sources

Clinical guidelines, reports, manuals, research papers, conversations, emails, and free-form analyst notes are designed primarily for human interpretation and may require construction before computational use.

Computational Sources

Models and algorithms also produce information. Examples include:

• LLM interpretations;
• classifier outputs;
• trajectory predictions;
• simulation results;
• optimization results;
• plans;
• logical conclusions;
• constraint-check results;
• and formal-verification results.

These outputs carry the provenance, assumptions, scope, and epistemic status of the computation that produced them.

Human Sources

Humans contribute observations, corrections, approvals, judgments, exceptions, and decisions. Their role and authority may matter computationally and should not automatically disappear into anonymous text.

4.4 Acquisition Preserves the Source

The first architectural task is often acquisition: obtaining source material while preserving enough metadata to know what was obtained and where it came from.

{
  "source_id": "caregiver-dialogue-42",
  "source_type": "conversation",
  "acquired_at": "2026-07-24T16:10:00Z",
  "source_version": "turn-7",

  "payload": {
    "text": "She's breathing much faster now."
  }
}

This record is not yet necessarily a knowledge object.

Keeping source material distinct from its interpretation allows the system to reprocess it, compare competing constructors, preserve corrections, and audit how a later knowledge object was created.

4.5 Knowledge Construction

Knowledge construction converts acquired information into objects that can participate in the Knowledge Runtime.

Construction may involve:

• parsing;
• entity identification;
• schema mapping;
• claim decomposition;
• type assignment;
• scope determination;
• provenance attachment;
• or model-assisted interpretation.

Source statement:
"She's breathing much faster now."

Constructed knowledge:

type:
    observation

subject:
    child-17

concept:
    increased_work_of_breathing

status:
    caregiver_reported

provenance:
    dialogue-turn-7

Source:
AIS position reports

Constructed knowledge:

type:
    trajectory_window

subject:
    vessel-204

observations:
    timestamped positions
    speed
    heading

provenance:
    AIS feed

status:
    observed

4.6 Construction Can Be Deterministic or Model-Assisted

Construction is itself computation and may be implemented in many ways.

Deterministic Construction

A deterministic constructor applies a known mapping.

Examples include:

• mapping a typed API response to a measurement;
• mapping database rows into knowledge objects;
• converting units;
• or translating an ontology identifier into an internal representation.

Model-Assisted Construction

A foundation model or specialized classifier may interpret natural language, imagery, or multimodal input and propose a structured construction.

source material
      ↓
model-assisted interpretation
      ↓
provisional knowledge
      ↓
ground / qualify / validate
      ↓
runtime knowledge

The use of a model does not make the result invalid. Nor should every model-produced construction automatically be treated as authoritative fact.

The important architectural requirement is to preserve what kind of result was produced.

4.7 Grounding and Normalization

Knowledge from heterogeneous sources rarely aligns automatically.

One source may use colloquial language, another an ontology identifier, another a database key, and another a model-specific label.

"pulling in between her ribs"
        ↓
ground
        ↓
concept:
    intercostal_retractions

subject:
    child-17

"the large fishing vessel"
        ↓
resolve
        ↓
MMSI 367123456
        ↓
vessel:367123456

Grounding may also involve:

• canonical identifiers;
• entity resolution;
• unit conversion;
• timestamp alignment;
• schema mapping;
• ontology mapping;
• feature alignment;
• and spatial normalization.

Uncertainty should not be erased during grounding. An uncertain entity match should remain uncertain and revisable.

4.8 Validation Is Relative to Computational Use

A constructed object is not simply valid or invalid in the abstract.

Its suitability depends on what the system intends to do with it.

For example, an LLM-generated hypothesis may be perfectly suitable for:

• starting an investigation;
• suggesting a question;
• or competing with another hypothesis;

while being unsuitable by itself for:

• authorizing a treatment;
• executing a safety-critical maneuver;
• or establishing a formally guaranteed property.

4.9 Retrieval Is Infrastructure; Activation Is Semantics

A Knowledge Native system may need to find knowledge stored across databases, graphs, documents, indexes, model registries, external services, and memory stores.

Retrieval can use:

• exact lookup;
• relational queries;
• graph traversal;
• semantic similarity;
• temporal and spatial filters;
• or combinations of these mechanisms.

But retrieval and activation answer different questions.

A retrieved pediatric guideline may not apply to the patient.

A trajectory model may be relevant to prediction but invalid for the current observation regime.

A verifier may exist but not be required for a low-consequence action.

Retrieval is therefore supporting infrastructure beneath ACTIVATE rather than a foundational Knowledge Native operator.

4.10 ACTIVATE: From Understanding to Relevant Expertise

ACTIVATE is the first of the A4 runtime operations.

It operates over both knowledge and computational expertise.

Activation may examine:

• scope;
• entity type;
• current observations;
• operating regime;
• prerequisites;
• missing evidence;
• the current goal;
• and the authority boundary being approached.

Current understanding:
    child with fever
    hydration adequate
    breathing not yet assessed

Intended outcome:
    home-monitoring recommendation

ACTIVATE:

    disposition requirement:
        respiratory status required

    respiratory assessment expertise

Current understanding:
    sufficient trajectory history
    crossing geometry possible
    future position unknown

ACTIVATE:

    trajectory prediction expertise

Activation is therefore more than retrieving knowledge or selecting a tool. It connects the current understanding to what must computationally happen next.

4.11 Computational Expertise as an Architectural Interface

Once expertise is activated, the runtime needs a common abstraction through which heterogeneous computation can participate.

Conceptually:

ComputationalExpert

    identity

    capability

    scope

    requirements

    knowledge_inputs

    implementation_binding

    result_type

    authority

Different experts may bind to very different implementations:

clinical_reasoner
    → foundation model

trajectory_predictor
    → transformer model

planner
    → search / planning service

constraint_checker
    → solver

physics_expert
    → numerical simulator

verification_expert
    → model checker

human_expert
    → review task

The Knowledge Runtime need not know the internal implementation of each expert.

It needs to know:

• when the expertise applies;
• what it requires;
• how to bind its inputs;
• what kind of result it returns;
• and what that result is permitted to establish.

4.12 APPLY: Put the Right Expertise to Work

APPLY is the point where activated knowledge and expertise perform useful computation.

A single runtime operation covers many very different forms of expertise:

APPLY(llm_clinical_reasoner)
    → proposes recommendation

APPLY(trajectory_predictor)
    → predicts future motion

APPLY(planner)
    → proposes feasible plan

APPLY(logical_reasoner)
    → derives consequence

APPLY(simulator)
    → computes physical outcome

APPLY(verifier)
    → establishes property

APPLY(constraint_solver)
    → determines admissibility

Prediction, planning, deduction, simulation, and verification are not separate Knowledge Runtime operators.

They are different computations hidden behind the common expert abstraction.

The actual execution may occur through:

• ordinary Python;
• a local model;
• a remote API;
• a workflow engine;
• an agent framework;
• MCP or another tool protocol;
• a distributed service;
• or a human task.

KnaiTai need not duplicate this execution infrastructure.

4.13 ABSORB: Computation Becomes Understanding

A result returning from an expert is not merely another message.

The runtime must determine what that result establishes and how the current understanding should change.

Consider a predictor:

APPLY:
    trajectory_predictor

RESULT:
    predicted_crossing = 0.82

ABSORB:

    type:
        prediction

    supports:
        potential_collision

    activates:
        collision_assessment

Or a verifier:

APPLY:
    safety_verifier

RESULT:
    proposed_plan violates constraint C7

ABSORB:

    plan_status:
        invalid

    invalidates:
        execution_candidate

    activates:
        replanning

ABSORB may therefore:

• introduce new knowledge;
• strengthen or weaken a hypothesis;
• supersede a previous result;
• invalidate dependent conclusions;
• establish a property;
• introduce a new knowledge gap;
• or make different expertise applicable next.

4.14 AUTHORIZE: From Understanding to Consequence

A Knowledge Native system should distinguish between producing a result and granting that result authority.

Authorization may require:

• particular evidence;
• specific expertise to have participated;
• constraints to be satisfied;
• a verification result;
• a provenance requirement;
• a human approval;
• or absence of unresolved blocking conditions.

AUTHORIZE:
    home_monitoring

requires:
    hydration assessed
    responsiveness assessed
    respiratory status assessed
    no escalation criterion active

result:
    DENIED

reason:
    respiratory status unknown

AUTHORIZE:
    execute maneuver

requires:
    trajectory estimate current
    feasible plan
    collision check passed
    dynamics check passed

result:
    ALLOWED

Authorization is not simply a confidence threshold.

A highly confident model recommendation may still lack a mandatory verification. A lower-confidence plan may still be authorized if the governing system explicitly permits action under that uncertainty.

4.15 The Knowledge Runtime

The central architectural component is therefore the Knowledge Runtime.

Its basic semantic cycle is A4:

while task_is_active:

    active = ACTIVATE(
        understanding
    )

    results = APPLY(
        active,
        understanding
    )

    understanding = ABSORB(
        understanding,
        results
    )

    authority = AUTHORIZE(
        understanding
    )

    if authority.permits_outcome():
        emit_or_act()

    else:
        continue

The cycle need not correspond to four physical function calls.

A real implementation may batch, parallelize, cache, defer, or distribute these operations.

A4 defines the semantics, not necessarily the scheduling strategy.

4.16 The Knowledge Runtime Is Not an Agent Orchestrator

This distinction deserves an explicit architectural boundary.

A LangGraph workflow, Temporal process, ROS graph, conventional Python application, model router, agent framework, or distributed service layer may execute the underlying computation.

KnaiTai need not replace any of them.

4.17 Missing Knowledge and Incomplete Computation

An activated expert may be relevant without yet being executable.

This occurs when required knowledge is missing.

respiratory assessment expertise

applicable:
    yes

requires:
    work_of_breathing

current state:
    work_of_breathing = UNKNOWN

result:
    NOT READY

The missing input becomes a knowledge gap.

That gap can itself change system behavior:

knowledge gap
      ↓
ACTIVATE
      ↓
question-generation expertise
      ↓
APPLY
      ↓
ask caregiver
      ↓
new observation
      ↓
ABSORB
      ↓
respiratory expert now executable

4.18 Incremental Understanding

A real Knowledge Native system should not rebuild its entire understanding after every new observation or expert result.

Knowledge and results have dependencies.

source observation
      ↓
constructed knowledge
      ↓
prediction
      ↓
risk assessment
      ↓
plan
      ↓
verification
      ↓
authority

If an upstream observation changes, the runtime can identify the affected region.

new observation
      ↓
ABSORB
      ↓
invalidate affected prediction
      ↓
reactivate predictor
      ↓
new prediction
      ↓
reconsider dependent risk / plan /
verification / authority

This is closely related to familiar systems ideas:

• incremental view maintenance;
• dependency tracking;
• cache invalidation;
• build systems;
• dataflow computation;
• and event-driven architectures.

Progressive understanding is therefore not simply a metaphor for the system “learning more.”

It is the incremental evolution of a computational state whose dependencies determine what must be reconsidered.

4.19 Knowledge Lifecycle

Knowledge also changes in status over time.

A runtime object may move through states such as:

constructed
    ↓
provisional
    ↓
validated
    ↓
available
    ↓
active
    ↓
absorbed into understanding
    ↓
superseded / invalidated / expired
    ↓
archived

Not all objects need every state, and this is not intended as a mandatory universal lifecycle.

The important principle is that temporal and epistemic changes can affect computation.

An expired observation may deactivate an expert. A superseded prediction may invalidate a plan. A newly verified result may satisfy an authorization requirement.

4.20 Running Example I: Caregiver Assistance

Consider an after-hours caregiver assistant.

A capable frontier model handles the natural conversation and much of the clinical reasoning.

The Knowledge Native architecture does not attempt to reproduce every capability of that model through rules.

Initial Information

Caregiver:

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

Construction

observed / reported:

age = 6
fever = true
vomiting = 2 episodes
responsive = true
drinking = true

unknown:

respiratory_status

ACTIVATE

The system is considering whether home monitoring may be recommended.

General disposition knowledge establishes:

home_monitoring requires:

    adequate responsiveness
    adequate hydration assessment
    respiratory status assessed

Respiratory status is missing.

AUTHORIZE

home_monitoring:

    NOT YET AUTHORIZED

missing:
    respiratory status

APPLY

The conversational expert asks:

How is she breathing? Do you see the skin pulling in between or underneath her ribs?

The caregiver reports:

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

ABSORB

new observation:

intercostal_retractions = true

status:
caregiver_reported

effect:

respiratory escalation knowledge
becomes applicable

ACTIVATE + APPLY

Respiratory clinical expertise evaluates the newly applicable knowledge.

AUTHORIZE

home_monitoring:
    BLOCKED

prompt evaluation:
    RECOMMENDABLE

The foundation model may independently reach exactly the same recommendation.

That is not a failure of the architecture.

4.21 Running Example II: Specialized Trajectory Expertise

Now consider a very different situation.

A system is monitoring a moving vessel and needs to determine whether it may enter a collision geometry.

Current Understanding

observations:
    recent positions
    timestamps
    heading
    speed

current gap:
    future trajectory

decision dependency:
    collision risk requires
    future trajectory

ACTIVATE

trajectory prediction expertise
    → applicable

requirements:
    sufficient trajectory window
    timestamps
    vessel context

requirements:
    satisfied

APPLY

trajectory_predictor(
    trajectory_window,
    vessel_context
)

→ predicted_future_track

ABSORB

predicted_future_track

type:
    prediction

provenance:
    trajectory-model-v7

effect:
    collision assessment
    now applicable

ACTIVATE Again

collision assessment expertise

Here the specialized computation was not added because the language model needed oversight.

It was activated because trajectory prediction itself calls for specialized computational expertise.

4.22 Running Example III: Planning and Verification

Consider an autonomous system with a goal and an evolving state.

A foundation model may propose a sensible high-level action.

But the system has explicit planning knowledge:

actions
preconditions
effects
resources
goals

ACTIVATE

goal requires multi-step action

→ planning expertise required

APPLY

planner(
    current_state,
    action_model,
    goal
)

→ candidate_plan

ABSORB

candidate_plan

type:
    proposal

not yet executable

ACTIVATE

safety verification expertise

APPLY

verify(candidate_plan)

→ constraints satisfied

ABSORB

candidate_plan:
    verified

AUTHORIZE

execute(candidate_plan)

→ ALLOWED

The architecture did not replace the planner or verifier.

It represented when each became computationally necessary and what its result meant to the system.

4.23 Architectural Interfaces

A practical implementation benefits from a small number of explicit interfaces.

interface KnowledgeSource:
    acquire(...) -> SourceItem


interface KnowledgeConstructor:
    construct(
        item,
        context
    ) -> list[KnowledgeObject]


interface ComputationalExpert:
    applicable(
        understanding
    ) -> ApplicabilityResult

    requirements(
        understanding
    ) -> RequirementSet

    apply(
        context
    ) -> ExpertResult


interface KnowledgeRuntime:
    activate(
        understanding
    ) -> ActivationSet

    absorb(
        understanding,
        result
    ) -> UnderstandingState

    authorize(
        understanding,
        target
    ) -> AuthorityResult

The exact programming interface may evolve.

The important separation is architectural:

• sources provide information;
• constructors create computational knowledge;
• experts perform specialized computation;
• the runtime controls A4 semantics;
• external orchestration executes the physical workflow.

4.24 Failure as a First-Class Runtime Condition

Knowledge Native computation should not silently convert uncertainty, missing requirements, failed expert execution, or ambiguous grounding into success.

Important failure modes include:

• a source cannot be acquired;
• an entity cannot be grounded;
• an expert is applicable but required input is missing;
• an expert invocation fails;
• a result is outside the expert's validated scope;
• two results conflict;
• verification fails;
• or authority requirements remain incomplete.

These conditions should remain explicit because they may themselves determine the next computation.

trajectory predictor:
    applicable

required history:
    20 observations

available:
    7 observations

runtime result:
    NOT READY

authority:
    collision assessment withheld

Failure therefore need not terminate the runtime.

It may produce a knowledge gap, activate another expert, request human input, trigger a fallback computation, or withhold authority.

4.25 Testing the Architecture

Testing should address more than whether the final answer looks reasonable.

Knowledge Construction Tests

• Is provenance preserved?
• Are general knowledge and runtime bindings kept separate?
• Are model-generated objects assigned appropriate epistemic status?

Activation Tests

• Does the correct knowledge activate in the intended context?
• Does irrelevant or out-of-scope knowledge remain inactive?
• Does the correct computational expertise become applicable?
• Are missing requirements surfaced?

Expertise Tests

• Are inputs bound correctly?
• Does the expert return the declared result type?
• Are assumptions and provenance retained?

ABSORB Tests

• Does the result change only the appropriate part of understanding?
• Are predictions preserved as predictions?
• Are invalidated dependencies reconsidered?
• Does the result activate the expected next expertise?

AUTHORIZE Tests

• Is authority withheld when mandatory evidence is missing?
• Can a failed verifier block an action?
• Can advisory results remain useful without receiving excessive authority?

Trace Tests

• Can the system identify why an expert was activated?
• Can it identify what the expert established?
• Can it identify why an action was allowed or denied?

4.26 Common Architectural Mistakes

Treating Every LLM Output as Established Knowledge

An LLM may produce excellent reasoning. Its output should nevertheless retain the semantics of what it produced: observation extraction, hypothesis, recommendation, plan, interpretation, or other result.

Over-Symbolizing What the LLM Already Does Well

Knowledge Native AI does not require replacing robust neural reasoning with duplicated symbolic machinery. Explicit structure should be introduced where it provides computational leverage.

Treating Retrieval as Activation

A retrieved item is merely available. ACTIVATE determines whether it matters to the current computation.

Treating Tool Use as Knowledge Native Computation

An agent calling a calculator, model, or search API does not by itself make the system Knowledge Native. The important question is whether the system represents why that expertise was required and what the result established.

Treating Multi-Agent Orchestration as the Abstraction

Agents may carry expertise, but so may models, planners, solvers, simulations, database queries, ordinary code, and humans.

Giving Every Result Equal Authority

A hypothesis, prediction, formally verified result, human approval, and safety constraint are not computationally interchangeable.

Embedding General Knowledge in Runtime Instances

General knowledge should be declared independently and bound to individual entities only when the runtime situation makes it applicable.

Overloading the Operator Set

Predict, plan, verify, constrain, retrieve, route, retry, reconcile, and explain are useful verbs, but they need not all become foundational Knowledge Native operators.

A4 provides the stable abstraction:

ACTIVATE
APPLY
ABSORB
AUTHORIZE

4.27 Knowledge Native Thinking

When designing an intelligent architecture, do not begin only by asking:

Which model should process the input?

Ask instead:

• What information enters the system?
• What knowledge should be constructed from it?
• What knowledge already exists?
• What is the current understanding?
• What needs to be established next?
• What computational expertise is appropriate?
• What requirements must be satisfied before it can run?
• What does its result establish?
• How does that result change understanding?
• What knowledge or expertise becomes relevant next?
• What recommendation, decision, or action now has sufficient authority?

Chapter Summary

• Knowledge Native architecture is centered on an evolving computational understanding rather than a single model invocation.
• Information, knowledge, and computational expertise are related but distinct architectural concepts.
• Sources may be structured, semi-structured, unstructured, computational, or human.
• Acquisition preserves original source material and provenance.
• Knowledge construction converts source information into objects suitable for runtime use.
• Grounding and normalization connect heterogeneous representations without erasing provenance or uncertainty.
• Validation is relative to intended computational use.
• Retrieval is supporting infrastructure; ACTIVATE determines what knowledge and expertise matter now.
• Computational expertise provides a common abstraction over LLMs, predictors, planners, solvers, simulators, verifiers, algorithms, external services, and humans.
• APPLY puts activated expertise to work without requiring KnaiTai to implement the internals of each expert.
• ABSORB determines what the result established and changes the evolving understanding accordingly.
• AUTHORIZE determines whether a recommendation, decision, or action has sufficient computational grounds to cross an authority boundary.
• The Knowledge Runtime owns semantic participation; existing workflow and agent infrastructure may own execution mechanics.
• Applicable expertise may still be unable to execute because required knowledge is missing.
• Dependencies allow understanding to be updated incrementally rather than reconstructed from scratch.
• Failure, uncertainty, and missing requirements are first-class runtime conditions.
• Testing should examine activation, expert participation, absorption, authority, and traceability rather than only final output quality.
• The stable architectural rhythm is ACTIVATE → APPLY → ABSORB → AUTHORIZE.

Discussion Questions

1. Why should information, knowledge, and computational expertise be represented as distinct architectural concepts?
2. When should source material become an explicit knowledge object?
3. Why is retrieval infrastructure different from activation semantics?
4. What information must a computational expert expose to the Knowledge Runtime?
5. Why should a prediction, plan, LLM interpretation, and formal-verification result be absorbed differently?
6. What makes AUTHORIZE different from applying a confidence threshold?
7. How should a Knowledge Runtime interact with existing agent and workflow frameworks?
8. What happens when expertise is applicable but required inputs are unavailable?
9. How do knowledge dependencies enable incremental recomputation?
10. When is it better to leave knowledge inside a capable foundation model rather than represent it explicitly?
11. What kinds of knowledge should remain stable even when the underlying foundation model changes?

Exercises

Exercise 4.1: Inventory Knowledge Sources

Choose an intelligent application and identify at least eight sources of information. Classify them as structured, semi-structured, unstructured, computational, or human.

Exercise 4.2: Construct Runtime Knowledge

Choose three source items and show how each becomes a knowledge object. Preserve source identity, scope, epistemic status, and computational role.

Exercise 4.3: Separate Knowledge from Expertise

For a predictor, planner, verifier, and foundation model, identify what knowledge each uses and what computational expertise each provides.

Exercise 4.4: Design ACTIVATE

Create an understanding state containing several observations and two unresolved goals. Specify which knowledge and experts ACTIVATE should make relevant and why.

Exercise 4.5: Design an Expert Interface

Specify a computational expert with:

• capability;
• scope;
• requirements;
• knowledge inputs;
• implementation binding;
• result type;
• and authority.

Exercise 4.6: Design ABSORB

Take one prediction, one LLM-generated hypothesis, and one verification result. Show how each should differently change the understanding state.

Exercise 4.7: Design an Authority Boundary

Choose one consequential recommendation or action. Specify exactly what evidence and computational expertise must participate before AUTHORIZE permits it.

Exercise 4.8: Separate Semantics from Orchestration

Design an architecture using an LLM, predictor, planner, and verifier. Identify which responsibilities belong to the Knowledge Runtime and which belong to workflow, tool, or agent infrastructure.

Exercise 4.9: Trace an Incremental Revision

Change one upstream observation and identify which knowledge objects, expert results, understanding elements, and authority decisions should be reconsidered.

Exercise 4.10: Build an A4 Trace

Construct a complete trace containing:

ACTIVATE
    ↓
APPLY
    ↓
ABSORB
    ↓
AUTHORIZE
    ↓
ACTIVATE again

At every stage, state what changed and why.