Chapter 2

Knowledge as a Computational Primitive

Chapter 1 argued that Knowledge Native AI puts knowledge to work at runtime. This chapter develops that idea into a programming abstraction. The objective is not to force every form of knowledge into one representation, but to give a running system enough semantics to determine what is known, what matters now, what computational expertise should be brought to bear, what its result establishes, and what the system is consequently permitted to recommend, decide, or do.

2.1 From Stored Knowledge to Knowledge That Shapes Computation

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

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

A constraint may be recorded but never checked. A retrieved passage may be added to a prompt without affecting a result. A model may contain powerful predictive knowledge but never be invoked when that prediction is actually required. A formal specification may exist while a proposed action bypasses its verifier.

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

More precisely, a Knowledge Native program asks continuously: What is known now? What does that knowledge make relevant? What must be computed next? What expertise should perform that computation? What did the result establish? What may the system now do?

Stored knowledge answers: What is available?
Active knowledge answers: What computational role does it have now?

For knowledge to become active, a system may need to determine:

what the knowledge asserts, encodes, or provides;
where it came from;
when and where it applies;
what epistemic status it has;
what computation it can shape or require;
what computational expertise can put it to work;
what the resulting computation establishes;
and how that result changes what happens next.

Knowledge Native AI is therefore not simply a method for attaching more information to an LLM. It is an attempt to give knowledge an explicit and inspectable role in a heterogeneous computational system.

2.2 What Makes Something a Computational Primitive?

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

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

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

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

The same principle applies to knowledge. If knowledge is to become a first-class computational primitive, the system must know how knowledge participates in computation.

But this does not require a large vocabulary of special-purpose knowledge operators. Support, challenge, prediction, planning, constraint checking, optimization, and verification are different kinds of computation. They need not each become primitive runtime operations.

Instead, Knowledge Native AI can expose a much smaller computational interface around them.

The A4 operators:

ACTIVATE — determine what knowledge and expertise matter now.
APPLY — put the appropriate knowledge and expertise to work.
ABSORB — incorporate what the computation established into the evolving understanding.
AUTHORIZE — determine what may now be recommended, decided, or done.

These four operations form the minimal computational vocabulary developed in this book.

2.3 From Facts to Knowledge Objects

Consider the following assertion:

Package P depends on library L.

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

A system may also need to know:

which version of P the dependency applies to;
which version range of L is required;
which manifest or build process asserted it;
whether the dependency is mandatory or optional;
when the assertion was last verified;
and which deployment or security conclusions depend upon it.

The bare fact records content. A knowledge object preserves content together with enough semantics for that knowledge to participate correctly in computation.

Definition 2.1 (Knowledge Object). A knowledge object is an identifiable computational unit that represents something known, proposed, observed, predicted, required, or assumed together with the provenance, scope, epistemic status, applicability, and operational semantics needed for its runtime use.

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

Some knowledge objects are relatively static, such as guidelines, constraints, planning domains, and specifications. Others belong to the evolving runtime understanding, such as observations, hypotheses, predictions, plans, and verification results.

A minimal conceptual structure might be written as:

KnowledgeObject
    identity
    content
    type
    provenance
    scope
    epistemic_status
    applicability
    computational_role
    dependencies

This is not intended as a universal schema. It identifies information that commonly determines how knowledge may participate in computation.

2.4 The Anatomy of a Knowledge Object

Identity

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

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

For example, observation:fever:child-17:2026-07-18T21:10 identifies one runtime observation. By contrast, guideline:respiratory-distress:retractions can identify general clinical knowledge whose applicability is evaluated against a particular patient only at runtime.

General knowledge is declared once. Runtime state binds that knowledge to the particular entities and situation to which it currently applies.

Content

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

Content may take many forms:

a proposition about an entity;
an observed measurement;
a relationship between objects;
a constraint on allowable states;
a procedure or action model;
a probability distribution;
a model or model reference;
a formal specification;
or a result produced by statistical or neural computation.

Knowledge Native computation does not require content to be natural language. Symbolic expressions, numerical structures, executable procedures, graph patterns, learned parameters, and references to computational artifacts may all participate.

Type

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

observation;
claim;
constraint;
rule;
prediction;
procedure;
hypothesis;
model;
specification;
plan;
verification result;
or human judgment.

Type matters because different forms of knowledge participate differently. An observation may change state. A constraint may eliminate a candidate. A planning model may become input to a planner. A specification may become input to a verifier.

Provenance

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

Provenance is more than citation. It may affect authority, reproducibility, conflict resolution, and auditability.

A clinical hypothesis proposed by an LLM and the same hypothesis established by a diagnostic test may have identical text but very different epistemic status and permitted consequences.

Scope

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

Scope may be temporal, geographic, organizational, task-specific, population-specific, version-specific, operating-regime-specific, or tied to a model's validated domain.

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

Epistemic Status

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

It may be observed, asserted, inferred, predicted, assumed, disputed, verified, superseded, or invalidated.

Confidence may be one component of epistemic status, but it is not the whole of it. A high-confidence prediction remains a prediction. A formally verified property is different from a model's high-confidence judgment. An authoritative constraint may have no probabilistic confidence score at all.

Applicability

Applicability captures the conditions under which knowledge may legitimately participate in the current computation.

A clinical guideline may apply to a particular age range and symptom pattern. A trajectory model may apply only to a particular vessel class, sampling regime, or operating region. A software invariant may apply only after initialization. A planning model may apply only when its state variables and action assumptions match the current problem.

Applicability is what allows general knowledge to become computationally active in a particular runtime situation.

Computational Role

A knowledge object may also indicate what it can do computationally or what kind of expertise can put it to work.

A constraint may restrict a candidate action. Historical trajectories may provide input to a predictor. A planning domain may provide the action semantics required by a planner. A clinical guideline may determine that a particular condition must be evaluated. A formal specification may be consumed by a verifier.

These are roles of knowledge. They are not additional top-level runtime operators.

2.5 Knowledge and Computational Expertise

Knowledge and computational expertise are closely related, but they should not be collapsed into one abstraction.

Knowledge is what is known.
Computational expertise is a bounded capability for putting relevant knowledge to work for a particular computational purpose.

A trajectory history is knowledge; predicting the future trajectory is expertise.

Actions, preconditions, effects, and goals are knowledge; searching them for a feasible plan is expertise.

A formal specification is knowledge; establishing whether a candidate satisfies it is verification expertise.

A set of clinical findings and guidelines is knowledge; applying a clinical pathway to determine what must be evaluated next is expertise.

The distinction remains useful even when knowledge is embodied in a trained model. A trajectory transformer contains learned knowledge about motion patterns, while its computational expertise is the capability to map an appropriate trajectory history to a future-motion prediction.

Likewise, a foundation model contains enormous learned knowledge while providing broad computational expertise in interpretation, synthesis, reasoning, and generation.

A computational expert can therefore expose an interface such as:

ComputationalExpert
    identity
    capability
    scope
    requirements
    knowledge_inputs
    implementation_binding
    result_type
    authority

The implementation behind that interface might be:

an LLM;
a predictor;
a planner;
a rule engine;
a solver;
a simulator;
an optimizer;
a verifier;
an ordinary algorithm or function;
an external service;
or a human expert.

The Knowledge Runtime can reason about what expertise is needed and why without requiring all expertise to be implemented in the same way.

2.6 The A4 Knowledge Operations

The objective of a foundational operator set should be to do more with less. Knowledge Native AI therefore distinguishes a small number of general operations from the many domain-specific computations that may occur underneath them.

Definition 2.2 (A4 Knowledge Operations). The core runtime operations of Knowledge Native AI are ACTIVATE, APPLY, ABSORB, and AUTHORIZE.

ACTIVATE

ACTIVATE determines what knowledge and computational expertise matter in the current state.

Activation evaluates such things as scope, applicability, prerequisites, current observations, unresolved questions, and the decision or action presently under consideration.

For example:

ACTIVATE(current_understanding)

→ respiratory_distress_guideline
→ respiratory_assessment_expertise

Activation does not necessarily execute anything. It establishes that some knowledge or expertise has become computationally relevant, eligible, or required.

Retrieval, indexing, graph search, semantic search, and filtering may help implement activation, but they are mechanisms rather than additional foundational operators.

APPLY

APPLY puts activated knowledge and appropriate computational expertise to work.

The actual computation may be extremely simple or highly specialized.

APPLY clinical_rule
    → CONSTRAINS home_monitoring

APPLY trajectory_predictor
    → PREDICTS future_position

APPLY planner
    → PROPOSES maneuver_plan

APPLY formal_verifier
    → VERIFIES maneuver_plan

APPLY llm
    → PROPOSES diagnostic_hypothesis

The uppercase terms on the right are not additional Knowledge Runtime operators. They describe the computational role of the result.

This distinction is important. KnaiTai does not need a primitive called PREDICT, another called PLAN, another called VERIFY, and another called CONSTRAIN. Those capabilities belong to different computational experts.

The common runtime operation is simply:

Apply this knowledge or expertise to the current problem.

Likewise, the mechanics of calling a model endpoint, Python function, planner, tool, or agent belong to execution infrastructure. They need not become separate knowledge operators.

ABSORB

ABSORB incorporates what a computation established into the system's evolving understanding.

Definition 2.3 (ABSORB). ABSORB incorporates a computational result into the evolving understanding according to its epistemic status, provenance, dependencies, and computational role.

Absorption is not merely collection or ingestion.

A result may:

add a new observation or conclusion;
strengthen or weaken a hypothesis;
replace a previous prediction;
invalidate a dependent conclusion;
establish that a constraint is satisfied;
introduce a candidate plan;
verify a property;
or change what knowledge and expertise become applicable next.

For example:

expert:
    trajectory_predictor

result:
    crossing_probability = 0.87

role:
    PREDICTION

ABSORB(result)

understanding:
    potential_crossing = supported
    collision_assessment = now_applicable

The important transition is not that another piece of information has been gathered. The system's computational understanding has changed.

Revision, reconciliation, dependency propagation, and invalidation may all occur as part of absorption. They are consequences or implementation mechanisms of this single semantic operation rather than independent foundational operators.

AUTHORIZE

AUTHORIZE determines what the current understanding permits the system to recommend, decide, or do.

Authorization may depend on:

required evidence being present;
particular expertise having been applied;
constraints being satisfied;
a verification result;
provenance or confidence requirements;
absence of unresolved blocking conditions;
or human approval.

For example:

AUTHORIZE(home_monitoring)

requires:
    respiratory_status_assessed
    no_active_red_flag

result:
    DENIED
    missing: respiratory_status_assessed

Or:

AUTHORIZE(execute_maneuver)

requires:
    feasible_plan
    collision_check_passed
    dynamics_check_passed

result:
    ALLOWED

Authorization is not equivalent to confidence. A model may be highly confident while a mandatory computation has not occurred. Conversely, an action may be authorized under uncertainty when the governing knowledge explicitly permits it.

2.7 Why Four Operators Are Enough

Many useful verbs arise naturally when describing intelligent systems:

retrieve, construct, support, challenge, constrain, transform, derive, predict, plan, verify, invoke, reconcile, revise, explain, and others.

These are real operations in software systems. But making all of them foundational Knowledge Native operators would confuse three different levels of abstraction.

First, there are runtime semantics. These are captured by A4.

Second, there are forms of computational expertise and result semantics. Prediction, planning, deduction, optimization, constraint solving, and verification belong here.

Third, there are execution and infrastructure mechanisms. Retrieval, indexing, API invocation, scheduling, retries, caching, routing, serialization, and logging belong here.

A4 deliberately sits above both specialized computation and execution machinery.

ACTIVATE determines what matters.
APPLY performs the appropriate computation.
ABSORB changes the understanding.
AUTHORIZE determines what may follow.

This separation allows the same runtime abstraction to survive changes in models, algorithms, storage systems, agent frameworks, and orchestration technologies.

2.8 Relevance, Applicability, and Requirement

Activation requires an important distinction among information that is related to a problem, knowledge that may legitimately participate, and knowledge or expertise that is actually required.

A retrieved document may discuss the correct topic but refer to an obsolete software version. A model may be generally relevant to trajectory prediction but invalid for the current sampling regime. A clinical guideline may apply to the patient but become computationally consequential only after a particular symptom is observed.

Definition 2.4 (Applicability). Knowledge or computational expertise is applicable when its scope, validity conditions, prerequisites, and status permit it to participate in the current computation.

Applicability may require checks such as:

Does it concern the correct entity or class of entities?
Is it valid at the relevant time?
Does it apply in the current environment, population, version, or operating regime?
Are its prerequisites satisfied?
Are the expert's required inputs available?
Has it been superseded, contradicted, or invalidated?

But applicable does not necessarily mean required.

Several experts may be capable of addressing a problem while none is mandatory. Conversely, governing knowledge may establish that a particular computation must occur before a recommendation or action can be authorized.

Relevant means related.
Applicable means legitimately usable now.
Required means an authority boundary cannot be crossed without it.

2.9 Presence Is Not Participation

Modern language-model and agent systems can assemble rich contexts containing user messages, retrieved passages, tool outputs, predictions, policies, and intermediate results. This is enormously useful. But placing information in a context window does not specify the computational role that information played.

Suppose a prompt contains:

a demand forecast;
a warehouse capacity limit;
a supplier delay notice;
and an analyst recommendation.

A language model may reason correctly over all four. But the surrounding application may still need to know that the forecast supported increased ordering, the capacity limit restricted feasible quantities, the supplier delay changed the situation, and an optimizer was required before a recommendation could be made.

ACTIVATE
    demand_forecast
    capacity_constraint
    inventory_optimizer

APPLY
    inventory_optimizer

    → proposes phased_order_plan

ABSORB
    phased_order_plan
    capacity_check

AUTHORIZE
    recommendation

    → ALLOWED

Presence is not participation. Information appearing in a prompt is not evidence that it played a known computational role.

This is not an argument against prompting or LLM reasoning. Often the LLM will perform the relevant reasoning correctly. The architectural question is whether a consequential computational relationship must remain explicit, testable, revisable, or mandatory independently of the model's discretion.

2.10 A Minimal Knowledge Runtime

The A4 operations provide a compact model of the Knowledge Runtime.

CURRENT UNDERSTANDING
        ↓
     ACTIVATE
        ↓
What knowledge and expertise
matter now?
        ↓
       APPLY
        ↓
Perform the appropriate
computation
        ↓
      ABSORB
        ↓
What has now been established?
How has understanding changed?
        ↓
    AUTHORIZE
        ↓
What may now be recommended,
decided, or done?
        ↓
UPDATED UNDERSTANDING
        ↺

The cycle is intentionally recursive.

Absorbing a result changes the current understanding. That change may activate new knowledge or expertise. A prediction may activate a risk model. A detected risk may activate a planner. A proposed plan may activate a verifier. Verification may finally provide sufficient authority for execution.

A simplified runtime can therefore be expressed as:

state = initial_understanding(input)

while not finished(state):

    active = ACTIVATE(state)

    results = APPLY(
        active,
        state
    )

    state = ABSORB(
        state,
        results
    )

    authority = AUTHORIZE(state)

    if authority.allows_output():
        return emit(
            state,
            authority,
            trace=True
        )

This is intentionally abstract. APPLY might result in an LLM call, database query, Python function, neural predictor, planner, theorem prover, optimizer, simulator, verifier, or human task.

The runtime does not need to implement all of those systems. It needs to know why they became relevant, what they require, what they establish, and what authority their results carry.

2.11 Knowledge, Expertise, and Orchestration

The distinction among knowledge, computational expertise, and orchestration is fundamental.

Knowledge represents what is known and the semantics of its use.
Computational expertise performs specialized computation with appropriate knowledge.
Orchestration executes and coordinates the underlying components.

A multi-agent framework might decide how messages move among a medical agent, pharmacy agent, and critic agent. A workflow engine might schedule a predictor and retry it after failure. A model router might select among foundation models for cost or latency.

Those are useful capabilities, but they address a different problem.

The Knowledge Runtime asks why a contraindication check became required, what knowledge it consumes, what result it establishes, how that result changes the current understanding, and whether the treatment recommendation may now proceed.

The component performing the check could be an agent, rule engine, database query, LLM, or ordinary function.

Agents are therefore one possible carrier of computational expertise. They are not the Knowledge Native abstraction.

Similarly, KnaiTai need not become a universal expert router. Routing asks which available component should receive a request. Knowledge Native activation asks what the evolving understanding makes computationally relevant or required.

2.12 Knowledge Objects Need Not Be True

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

An intelligent system must represent uncertain observations, competing hypotheses, model predictions, disputed claims, provisional plans, assumptions, and assertions later shown to be false.

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

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

This becomes especially important when heterogeneous expertise participates.

A predictor produces a prediction, not an observation. A planner produces a candidate plan, not proof of feasibility. An LLM may produce a hypothesis. A verifier may subsequently establish a stronger property about one of those results.

ABSORB must preserve these distinctions rather than collapsing heterogeneous computational products into an undifferentiated collection of facts.

2.13 Knowledge Capsules

Individual knowledge objects are useful primitives, but practical systems often need a larger portable unit that packages related knowledge with the semantics needed for runtime computation.

A knowledge capsule can group knowledge, scope, applicability, requirements, computational expertise bindings, result semantics, authority conditions, and provenance without requiring the underlying implementation to live physically inside the capsule.

KnowledgeCapsule
    identity
    knowledge
    scope
    applicability
    requirements
    expertise_binding
    result_semantics
    authority
    provenance

For example, a clinical capsule might contain general respiratory-distress knowledge and bind it to pathway evaluation expertise. A trajectory capsule might describe the scope and requirements of a trained predictor and bind to a model service. A verification capsule might package a specification and bind to a formal checker.

The capsule therefore provides a declarative boundary between what the Knowledge Runtime needs to know about a capability and how that capability is implemented and executed.

The A4 operators act over these abstractions:

ACTIVATE(capsule, understanding)

APPLY(capsule.expertise, knowledge)

ABSORB(result, understanding)

AUTHORIZE(action, understanding)

Later chapters develop the capsule and runtime abstractions in greater detail.

2.14 Why the Abstraction Matters

The value of A4 is not the four names themselves. The value is the separation they create.

Application developers should not need to hard-code every possible combination of model, rule, predictor, planner, verifier, and decision boundary into one growing procedural workflow.

Nor should KnaiTai attempt to standardize every form of intelligence into one universal reasoner.

Instead, the runtime can operate over a stable abstraction:

What matters?
    → ACTIVATE

What computation should occur?
    → APPLY

What did it establish?
    → ABSORB

What does that now permit?
    → AUTHORIZE

Everything beneath APPLY may continue to evolve.

Today's frontier LLM may be replaced by tomorrow's. A trajectory predictor may be retrained. A symbolic planner may be exchanged for a neural planner. A verifier may move from handcrafted constraints to a formal solver. An external service may replace a local implementation.

The Knowledge Native semantics need not change simply because the implementation of expertise changes.

This is the abstraction boundary.
KnaiTai programs the participation of knowledge and expertise, not the internal implementation of every expert.

Knowledge Native Thinking

When encountering a source of knowledge, ask not only what it contains, but what role it can play in a running computation.

A document is not yet an instruction. A graph edge is not automatically a constraint. A model is not automatically applicable. A prediction is not an observation. A planner's output is not automatically executable. A human note is not automatically authoritative.

Instead, ask four questions:

ACTIVATE: Does this knowledge or expertise matter now?

APPLY: What computation should be performed with it?

ABSORB: What did that computation establish, and how does it change the current understanding?

AUTHORIZE: What may the system now recommend, decide, or do?

These four questions provide the basic computational rhythm of a Knowledge Native program.

Chapter Summary

Knowledge may exist in a system without participating explicitly in computation.
A computational primitive is defined both by representation and by meaningful operations.
Knowledge may be declarative, situational, historical, structural, procedural, formal, learned, or human.
A knowledge object represents content together with computationally relevant identity, provenance, scope, epistemic status, applicability, role, and dependencies.
General domain knowledge should remain distinct from runtime bindings to particular entities and situations.
Knowledge and computational expertise are distinct: knowledge is what is known; expertise is the bounded capability to put appropriate knowledge to work.
Computational expertise may be provided by LLMs, predictors, planners, solvers, simulators, optimizers, verifiers, algorithms, external services, or humans.
Knowledge Native AI uses four foundational runtime operations: ACTIVATE, APPLY, ABSORB, and AUTHORIZE.
ACTIVATE determines what knowledge and expertise matter in the current understanding.
APPLY puts the appropriate knowledge and expertise to work.
ABSORB incorporates what the computation established into the evolving understanding.
AUTHORIZE determines what the resulting understanding permits the system to recommend, decide, or do.
Support, challenge, prediction, planning, constraint checking, optimization, and verification are computational roles or forms of expertise rather than additional foundational operators.
Retrieval, invocation, scheduling, routing, caching, and retries are execution mechanisms rather than foundational knowledge operations.
Existing workflow and multi-agent infrastructure can therefore execute computations without becoming the Knowledge Native abstraction itself.
A knowledge capsule provides a declarative boundary connecting knowledge, applicability, expertise, result semantics, and authority.

Discussion Questions

Are ACTIVATE, APPLY, ABSORB, and AUTHORIZE sufficient to describe the essential knowledge semantics of an intelligent system?
Which properties of a knowledge object appear universal, and which are necessarily domain-specific?
How is a knowledge object different from an ordinary typed record containing metadata?
When should a learned model itself be represented as knowledge, and when should it be represented as computational expertise?
Can the same knowledge participate in several different computational experts?
What is the difference between expertise that is applicable and expertise that is required?
What information must a computational result expose for ABSORB to interpret it correctly?
When should AUTHORIZE depend on a particular computation having occurred rather than merely on the final result?
Which mechanisms belong below APPLY rather than in the Knowledge Runtime itself?
How should KnaiTai interoperate with an existing workflow or agent framework without duplicating orchestration?

Exercises

Exercise 2.1: Identify Hidden Knowledge

Choose a familiar software or AI system. Identify at least five pieces of knowledge currently embedded in source code, configuration, prompts, models, databases, or human procedures. For each one, state its content, source, scope, epistemic status, and computational role.

Exercise 2.2: Separate General Knowledge from Runtime State

Choose a general rule or guideline and represent it independently of any particular subject. Then create a runtime observation for one concrete subject and show how ACTIVATE can make the general knowledge applicable to that subject without duplicating or rewriting the rule.

Exercise 2.3: Knowledge or Expertise?

Classify each of the following into knowledge, computational expertise, or both: a trajectory history, a trained trajectory transformer, a planning domain, an A* planner, a clinical guideline, an LLM, a formal specification, and a model checker. Explain each classification.

Exercise 2.4: APPLY Different Expertise

Choose one problem that requires at least three different forms of computational expertise. For each expert, identify the knowledge it consumes, what computation it performs, and the semantic role of the result it produces.

Exercise 2.5: ABSORB a Result

Construct a case in which a new computational result does more than add information. Show how absorbing it changes a hypothesis, invalidates a prior conclusion, or activates additional expertise.

Exercise 2.6: Define an Authority Boundary

Choose one consequential recommendation or action. Specify what knowledge and computational results must exist before AUTHORIZE permits it to proceed.

Exercise 2.7: Trace an A4 Cycle

Construct a short computational trace:

ACTIVATE
    ↓
APPLY
    ↓
ABSORB
    ↓
AUTHORIZE
    ↓
ACTIVATE ...

Identify exactly what changes at each step and why the next step follows.

Exercise 2.8: Separate Semantics from Orchestration

Sketch a system using an LLM, one specialized computational expert, and one verifier. Identify the A4 semantics separately from the workflow mechanics used to call and coordinate those components.