Chapter 3

Thinking in Knowledge

How problem formulation changes when knowledge becomes a first-class runtime abstraction: shaping what computational expertise should be brought to bear, how its results change an evolving understanding, and what the system may consequently recommend, decide, or do.

3.1 Abstractions Change How We Think

Computer science advances not only through faster machines or more powerful algorithms, but through better abstractions. An abstraction gives programmers a new vocabulary for describing computational problems. Once introduced, it changes what can be expressed naturally, what can be hidden safely, and which operations become available.

Procedural programming encouraged programmers to think in sequences of instructions. Object-oriented programming foregrounded objects, state, interfaces, and behavior. Functional programming emphasized transformation, composition, and immutable values. Relational databases replaced direct manipulation of files with relations and declarative queries. Machine learning made it possible to express some computations through models learned from examples rather than through explicitly written rules.

Each of these developments altered more than implementation. It altered problem formulation.

A programmer working with files may ask where a record is stored. A programmer working with relations asks which tuples satisfy a predicate. A programmer working with objects asks which entity owns a behavior. A programmer working with a learned model asks which function can be estimated from data.

Knowledge Native AI proposes another shift in viewpoint. Instead of asking only:

What computation should the system perform?

we also ask:

What is known now? What remains unresolved? What knowledge matters to the current situation? What computational expertise should be brought to bear? What will its result establish? And what may the system do after that result is absorbed?

Definition 3.1 (Thinking in Knowledge). Thinking in knowledge is the practice of formulating computational problems around the runtime evolution of knowledge: what is currently known, what remains unresolved, what expertise becomes applicable, what its computation establishes, how the result changes understanding, and what authority consequently follows.

This does not eliminate ordinary computation. Algorithms, data structures, databases, learned models, planners, solvers, simulators, and foundation models remain essential. The shift is that they are treated as computational experts participating within a larger knowledge process.

3.2 Representation Exposes Computation

A foundational lesson of computer science is that representation determines computation. The same underlying information may admit very different operations depending on how it is represented.

A graph stored as an adjacency matrix supports constant-time edge lookup but may consume substantial space. The same graph stored as adjacency lists makes traversal efficient for sparse structures. A mathematical expression stored as text is different from the same expression represented as an abstract syntax tree. A collection of observations stored as isolated strings is different from the same observations represented as typed, linked, and revisable knowledge objects.

Representation is therefore not merely a storage decision. It determines which questions are easy to ask, which invariants can be enforced, which transformations are composable, and which dependencies can be followed.

Computer Science Principle. Representation does not merely preserve information. It exposes a particular space of possible computations.

The same principle applies to knowledge.

When computationally important knowledge exists only implicitly in prose, application code, model parameters, prompts, or developer assumptions, the system may still make use of it. But the surrounding architecture may be unable to determine its scope, track its dependencies, know when it should activate another computation, or control what consequences it is allowed to have.

Once important knowledge becomes computationally accessible, additional possibilities emerge:

a clinical requirement can determine that more evidence must be gathered;
a physical constraint can determine that an action is inadmissible;
a trajectory history can activate a specialized predictor;
a planning domain can become input to a planner;
a formal specification can require verification;
a new observation can invalidate dependent conclusions;
and one expert's result can activate different expertise next.

This does not require all knowledge to be symbolic or stored in a graph. The essential requirement is that knowledge whose computational role matters becomes accessible enough for the runtime to use it correctly.

3.3 From Values to Knowledge-Bearing Values

Traditional programs manipulate values:

# Caregiver observation
temperature = 39.2
rib_retractions = True

# Operational observation
speed = 1.8
heading = 137.0

In an ordinary program, the surrounding code supplies the interpretation. The programmer knows what each variable refers to, where it came from, when it was measured, and what operations are appropriate.

In knowledge-intensive computation, the value alone may be inadequate. The system may also need to know:

where the value originated;
when it was observed or computed;
which entity and situation it concerns;
whether it is observed, predicted, inferred, or assumed;
whether it remains valid;
which computational expert produced it;
which assumptions were used to produce it;
and which later conclusions or authority decisions depend upon it.

Definition 3.2 (Knowledge-Bearing Value). A knowledge-bearing value is a value represented together with enough semantic and contextual information to determine how, where, and under what conditions it may participate in computation.

Caregiver assistance. The value 39.2°C becomes more useful when represented together with the child's age, time of observation, measurement source, and status as a caregiver-reported observation.

Trajectory prediction. The value 1.8 knots becomes meaningful when connected to a particular vessel, timestamp, trajectory history, sensor source, geographic context, and operating regime.

A knowledge-bearing value need not contain every imaginable annotation. It contains the contextual information required by the computations in which it participates.

This resembles the distinction between an untyped memory location and a typed value. Knowledge-bearing values extend this idea beyond type to provenance, scope, epistemic status, dependencies, and computational consequence.

3.4 From Program State to Understanding State

Programs evolve by changing state. Variables are assigned, objects are modified, files are written, and database rows are updated. Program state captures what is currently true about execution.

Knowledge Native systems also maintain what is currently observed, inferred, predicted, proposed, constrained, verified, unresolved, or assumed about the subject being addressed.

Definition 3.3 (Knowledge State). A knowledge state is the system's current structured representation of knowledge available to a computational task.

A knowledge state may contain far more than is relevant to one immediate problem. An understanding state organizes the active portion of that knowledge around the particular person, object, situation, process, or phenomenon currently being reasoned about.

Definition 3.4 (Understanding State). An understanding state is the task-focused organization of what is currently established, unresolved, predicted, proposed, constrained, or verified about a particular subject of reasoning.

Observations / Current State
        ↓
Current Understanding
        ↓
ACTIVATE
        ↓
Applicable Knowledge + Expertise
        ↓
APPLY
        ↓
Computational Result
        ↓
ABSORB
        ↓
Revised Understanding
        ↓
AUTHORIZE
        ↓
Recommend / Decide / Act

Caregiver assistance.

Current understanding:
    fever observed
    vomiting observed
    child responsive
    hydration partially assessed
    respiratory status unknown

Current consequence:
    home monitoring not yet authorized

Relevant next expertise:
    respiratory assessment

Autonomous navigation.

Current understanding:
    vessel approaching crossing geometry
    future encounter uncertain

Relevant next expertise:
    trajectory prediction

Possible later expertise:
    collision assessment
    planning
    maneuver verification

A new observation therefore does more than produce another output. It changes the state against which earlier and later knowledge and expertise become applicable.

3.5 Decomposing Problems Through A4

Chapter 2 introduced a deliberately small operator set:

ACTIVATE → APPLY → ABSORB → AUTHORIZE

Thinking in knowledge means using these four operations as the stable vocabulary for decomposing how intelligent computation proceeds.

Conventional formulation	Knowledge Native formulation
Choose a model or tool	ACTIVATE: determine what knowledge and expertise matter now
Run the model	APPLY: put the appropriate expertise to work
Consume the output	ABSORB: determine what the result established and revise understanding
Return an answer or execute	AUTHORIZE: determine what the resulting understanding permits
Handle missing input	Represent the missing knowledge and allow it to affect activation or authorization
Re-run after a change	Reconsider only the affected understanding, dependencies, and expertise
Explain the result	Expose the trace of what actually activated, computed, changed, and authorized

Abstraction Criterion. A useful knowledge abstraction exposes a small set of stable operations while hiding unnecessary representational and implementation detail.

A4 therefore does not attempt to make predict, plan, verify, constrain, deduce, or optimize into separate foundational operators.

Those are different forms of computational expertise.

Likewise, retrieval, API invocation, scheduling, retries, caching, routing, and message passing are execution mechanisms rather than foundational knowledge operations.

The abstraction remains stable above both.

3.6 Knowledge Dependencies and Incremental Understanding

Dependency is already a central computational idea. Build systems record which artifacts depend on which source files. Spreadsheets track which cells depend on other cells. Compilers construct dependency graphs among declarations and expressions. Incremental databases update derived views when source relations change.

Understanding also has dependencies.

A conclusion may depend on several observations. A prediction may depend on a particular history window. A plan may depend on state estimates and action assumptions. An authority decision may depend on both a proposed result and a verification result.

Definition 3.5 (Knowledge Dependency). A knowledge dependency records that the validity, applicability, status, interpretation, or authority of one knowledge object or result depends upon another.

Caregiver assistance.

reported reduced urination
        ↓
hydration concern
        ↓
home-monitoring assessment

If the caregiver later corrects the history and reports recent urination, the hydration-related understanding should change. An independently established respiratory concern should not.

Autonomous navigation.

trajectory history
        ↓
trajectory prediction
        ↓
collision estimate
        ↓
candidate maneuver
        ↓
verification
        ↓
execution authority

If new trajectory observations materially change the prediction, the downstream collision estimate, plan, verification, and authority decision may need reconsideration.

Explicit dependencies make revision computationally manageable. The system need not reconstruct its entire understanding after every change. It can identify and update the affected region.

This connection to incremental computation is important. Many Knowledge Native problems resemble familiar systems problems in dependency tracking, invalidation, caching, view maintenance, and change propagation.

3.7 Knowledge and Computational Expertise

Knowledge and computational expertise are closely connected, but they are not the same thing.

Knowledge is what is known.
Computational expertise is the capability to put appropriate knowledge to work for a particular computational purpose.

A clinical guideline is knowledge. Applying a pathway to a patient state is expertise.

A trajectory history, context, and learned motion patterns are knowledge. Predicting future motion is expertise.

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

A formal specification is knowledge. Establishing that a design or plan satisfies it is verification expertise.

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

The system may therefore have access to many kinds of computational experts:

Foundation Model
Predictor
Planner
Logical Reasoner
Constraint Solver
Optimizer
Simulator
Verifier
Database Computation
Human Expert

The important design question is not which of these becomes the universal intelligence.

It is:

Which expertise is appropriate for the computation that matters now?

3.8 The Knowledge Runtime

The Knowledge Runtime connects evolving understanding to computational expertise.

Its role is semantic rather than primarily logistical.

At runtime it should be able to determine:

what knowledge is currently relevant;
what expertise is applicable;
what evidence or inputs that expertise requires;
what computation should now occur;
what the result establishes;
how the understanding should change;
what becomes relevant next;
and what authority the resulting state supports.

CURRENT UNDERSTANDING
        ↓
ACTIVATE
        ↓
knowledge / expertise required
        ↓
APPLY
        ↓
specialized computation
        ↓
ABSORB
        ↓
updated understanding
        ↓
AUTHORIZE
        ↓
continue / recommend / decide / act
        ↓
        ↺

This cycle produces progressive understanding for a concrete computational reason: each result can change the state enough that different knowledge and expertise become relevant next.

3.9 Runtime Semantics Are Not Orchestration

Modern AI systems increasingly use workflow engines, agent frameworks, tool protocols, model routers, schedulers, and distributed services.

Knowledge Native AI should leverage this infrastructure rather than attempt to replace it.

The Knowledge Runtime determines why a computation matters and what its result means.
Execution infrastructure determines how that computation is called, scheduled, retried, routed, or distributed.

For example, the runtime may determine:

a trajectory prediction is now required;
the predictor's necessary inputs are available;
its output must be treated as a prediction rather than an observation;
the result may activate collision assessment;
and execution cannot be authorized until verification succeeds.

An existing workflow or agent framework may then:

call the predictor service;
manage credentials;
retry on failure;
parallelize independent work;
route a model call;
and invoke the verifier.

Similarly, an agent is one possible carrier of computational expertise. It is not the abstraction itself.

A computational expert may instead be a planner, transformer, SQL query, theorem prover, Python function, simulation, external service, or human.

Knowledge Native AI is not multi-agent orchestration.
It provides an abstraction over the knowledge semantics of heterogeneous computation.

3.10 Revision, Versioning, and Time

Software systems already treat change as a first-class concern. Databases provide transactions. Version-control systems preserve histories. Event-sourced architectures record transitions. Distributed systems reason about ordering, consistency, and stale replicas.

Knowledge changes as well. Observations become outdated. Sources are corrected. Assumptions cease to hold. Models are replaced. New evidence strengthens or weakens earlier interpretations.

Definition 3.6 (Knowledge Revision). Knowledge revision is the controlled modification of an understanding in response to new evidence, changed assumptions, corrected sources, or new computational results.

Revision is primarily a consequence of ABSORB.

Caregiver assistance. A caregiver initially reports no urination since morning, then later learns that the child urinated several hours ago. Absorbing the corrected observation should revise the hydration-related understanding without disturbing unrelated respiratory evidence.

Trajectory prediction. A predictor initially estimates a crossing trajectory. New motion observations arrive and the predictor is applied again. The new result supersedes the previous prediction and may invalidate downstream collision estimates and plans.

Revision is therefore not equivalent to assigning a new value. Dependencies determine which parts of understanding are affected.

Versioning becomes part of reasoning. An explanation of a past recommendation or action should be grounded in the knowledge and computational results available at the time, not only in what the system knows now.

3.11 Knowledge Gaps and Productive Uncertainty

Traditional programs are often designed around complete inputs. When a required value is absent, the program may fail, return a null value, or apply a default.

Knowledge-intensive systems routinely operate under incomplete information. Missing knowledge may itself determine what computation should happen next.

Definition 3.7 (Knowledge Gap). A knowledge gap is an explicitly represented absence whose resolution may affect applicability, understanding, computational requirements, or authority.

A knowledge gap is more informative than an unknown value.

It may specify:

what is missing;
why it matters;
which expertise depends upon it;
which recommendation or action is blocked by it;
and how it could be resolved.

respiratory_status = UNKNOWN
        ↓
home_monitoring authorization blocked
        ↓
ACTIVATE respiratory assessment
        ↓
APPLY conversational / clinical expertise
        ↓
ABSORB new observation

Or:

future_trajectory = UNKNOWN
        ↓
collision assessment cannot proceed
        ↓
ACTIVATE trajectory prediction
        ↓
APPLY predictor
        ↓
ABSORB prediction

Productive Uncertainty. A well-represented unknown is not merely a limitation. It can become a computational requirement.

3.12 Computational Authority

Producing a result and having authority to rely upon that result are different things.

A foundation model may propose a recommendation. A predictor may estimate a future state. A planner may produce a candidate plan. A verifier may establish that a required property holds.

Those outputs need not carry identical authority.

Definition 3.8 (Computational Authority). Computational authority is the permission granted to a computational result to inform, recommend, decide, constrain, authorize, or execute at a specified boundary within the system.

The amount and type of expertise required before authority is granted depends on the consequence of the outcome.

For a low-consequence conversational task, foundation-model reasoning alone may be enough.

For a clinical recommendation, selected guideline, contraindication, or safety expertise may be required.

For an autonomous action, prediction, planning, physical constraints, and independent verification may all need to participate before execution authority is granted.

Trust is earned.
In a Knowledge Native system, some of that trust can be earned computationally before a recommendation, decision, or action crosses its authority boundary.

3.13 Knowledge Traces and Explanation

An output alone rarely reveals the structure of the computation that produced it. Conventional systems address this through logs, stack traces, provenance records, and execution plans.

Knowledge Native systems require an analogous record of actual computational participation.

Definition 3.9 (Knowledge Trace). A knowledge trace is a structured record of the knowledge, computational expertise, results, dependencies, A4 transitions, and authority decisions that materially contributed to an outcome.

A knowledge trace is not necessarily a natural-language explanation. It is the computational structure from which explanations can be generated.

A model-generated rationale is also not automatically a knowledge trace. It may be plausible prose without corresponding to the computations that actually occurred.

A proper trace might record:

ACTIVATE
    respiratory_assessment

APPLY
    clinical_conversation_expert

RESULT
    rib_retractions = observed

ABSORB
    respiratory_distress = supported

ACTIVATE
    escalation_guideline

APPLY
    guideline_evaluator

RESULT
    home_monitoring = constrained

ABSORB
    escalation_requirement

AUTHORIZE
    home_monitoring
    → DENIED

This is not merely explainability. It is the execution history of knowledge participating in computation.

Knowledge traces support:

debugging incorrect conclusions;
identifying stale or weak inputs;
comparing alternative derivations;
auditing consequential decisions;
revising affected conclusions;
testing authority boundaries;
and generating audience-appropriate explanations.

3.14 Selective Explicitness

Treating knowledge as first-class does not mean representing everything explicitly. Such a goal would be unnecessary, expensive, and often counterproductive.

Definition 3.10 (Selective Explicitness). Selective explicitness is the principle that knowledge should be represented explicitly when its provenance, scope, applicability, dependencies, computational role, or authority materially affect system behavior.

This principle becomes more important, not less, as foundation models improve.

If a capable foundation model can reliably maintain ordinary conversational state, interpret a straightforward observation, or apply routine background knowledge, there may be little value in reimplementing all of that reasoning elsewhere.

Use neural intelligence aggressively where it is sufficient.

Make knowledge explicit where doing so provides important computational leverage:

it determines what expertise must run;
it defines the valid scope of a specialized computation;
it establishes required evidence;
it constrains or blocks an action;
it defines dependencies that must survive revision;
it must remain stable across model upgrades;
or it has consequences too important to leave entirely to model discretion.

The objective is not to externalize everything a model knows.
It is to make computationally consequential knowledge explicit where the system benefits from controlling its role.

3.15 A Method for Thinking Like a Knowledge Native Programmer

A conventional programmer often begins by asking which data structures, algorithms, models, databases, tools, or services are required.

A Knowledge Native programmer asks those questions, but begins one level earlier.

1. Identify the Subject and Intended Outcome

What person, object, process, situation, or phenomenon is the system reasoning about?

What might the system ultimately need to predict, recommend, decide, plan, verify, or do?

2. Describe the Current Understanding

What is presently observed, inferred, predicted, proposed, assumed, constrained, verified, or unresolved?

3. Identify the Knowledge

What relevant knowledge exists?

situational;
historical;
declarative;
structural;
procedural;
formal;
learned;
or human.

4. Identify the Computational Expertise

What expertise is appropriate for the computations that matter?

foundation model;
predictor;
planner;
logical reasoner;
solver;
simulator;
optimizer;
verifier;
database computation;
ordinary algorithm;
or human expert.

Do not introduce specialized computation simply because it exists. Use it where its expertise matters.

5. Define Activation

Under what conditions does each item of knowledge or expertise matter?

What must be true before it should participate?

6. Define What APPLY Establishes

When the expert runs, what kind of result does it produce?

Is it:

an observation;
a hypothesis;
a prediction;
a candidate plan;
a constraint result;
a verified property;
or a human judgment?

7. Define How ABSORB Changes Understanding

What new knowledge becomes established?

What is strengthened, weakened, superseded, invalidated, or made newly applicable?

8. Define the Authority Boundary

What may the system now do?

What additional evidence or expertise is required before it may:

inform;
recommend;
decide;
approve;
or act autonomously?

Caregiver assistant. A foundation model may conduct the conversation and perform much of the clinical interpretation. The runtime need not duplicate all of that capability. Selected clinical knowledge may instead determine that respiratory status is required before home monitoring can be authorized. If respiratory concerns appear, more specialized clinical expertise becomes applicable.

Trajectory prediction. The current state contains recent motion history and contextual knowledge. When future position becomes consequential, the runtime activates specialized trajectory expertise. The predictor's result is absorbed as a prediction, which may then activate collision analysis or planning.

Autonomous planning. A goal and current state may activate planning expertise. The resulting candidate plan is absorbed as a proposal, not yet as an executable action. Verification expertise may then become required before AUTHORIZE grants execution authority.

3.16 Thinking Beyond the Next Model Call

The deeper shift is in decomposition.

A problem need not be divided only into:

ingestion
    ↓
prompt
    ↓
model
    ↓
tools
    ↓
output

Nor should every problem be reframed as a collection of cooperating agents.

Instead, Knowledge Native decomposition asks:

What is known?
        ↓
What matters now?
        ↓
ACTIVATE
        ↓
What expertise should compute?
        ↓
APPLY
        ↓
What did it establish?
        ↓
ABSORB
        ↓
What may happen now?
        ↓
AUTHORIZE

The result of ABSORB may immediately change what becomes relevant, causing the cycle to continue.

This is where progressive understanding becomes computational rather than rhetorical.

3.17 The Abstraction Boundary

Knowledge Native AI is not an attempt to build one universal reasoning engine.

It is an abstraction over heterogeneous knowledge computation.

                    APPLICATION
                         ↓

                 KNOWLEDGE RUNTIME

             ACTIVATE
             APPLY
             ABSORB
             AUTHORIZE

                         ↓

              COMPUTATIONAL EXPERTISE

    LLM   Predictor   Planner   Solver   Verifier
     |        |          |        |         |
     +--------+----------+--------+---------+

                         ↓

             EXISTING EXECUTION /
             ORCHESTRATION LAYER

The application should be able to reason about:

what is known;
what expertise exists;
when it applies;
what it establishes;
how its result changes understanding;
and what authority follows;

without requiring the Knowledge Native abstraction to define the internal implementation of every LLM, predictor, planner, solver, simulator, verifier, or workflow engine.

This is the abstraction.
Knowledge Native programming defines the semantics of heterogeneous knowledge computation while hiding unnecessary implementation detail beneath the expert interface.

Knowledge Native Thinking

When approaching an intelligent system, resist starting with:

Which model should we use?

Instead ask:

What do we know?
What remains unresolved?
What knowledge matters now?
What computational expertise is appropriate?
What should that computation establish?
How should the result change the understanding?
What does the system now have authority to recommend, decide, or do?

Thinking in knowledge means thinking beyond the next model call.
It means programming how knowledge activates computation, how computation becomes new knowledge, and how an evolving understanding earns authority.

That shift is the starting point for programming Knowledge Native AI.

Chapter Summary

Programming abstractions change how computational problems are formulated.
Representation determines which forms of knowledge computation become possible and natural.
Knowledge-bearing values extend ordinary values with computationally relevant provenance, scope, status, dependencies, and consequence.
Knowledge state records what is available; understanding state organizes what currently matters to a particular task or situation.
Knowledge Native computation can be formulated through four foundational operations: ACTIVATE, APPLY, ABSORB, and AUTHORIZE.
ACTIVATE determines what knowledge and computational expertise matter now.
APPLY puts the appropriate expertise to work.
ABSORB determines what the computation established and updates the evolving understanding.
AUTHORIZE determines what the resulting understanding permits the system to recommend, decide, or do.
Knowledge and computational expertise are distinct: knowledge is what is known; expertise is the capability to compute with appropriate knowledge for a particular purpose.
Foundation models provide powerful general computational expertise and may remain primary in many applications.
Specialized expertise may include predictors, planners, logical reasoners, solvers, simulators, optimizers, verifiers, database computations, and humans.
The Knowledge Runtime determines the semantics of computational participation; existing workflow and agent systems may handle execution mechanics.
Knowledge dependencies support incremental revision rather than complete recomputation.
Knowledge gaps can become explicit runtime requirements.
Computational authority distinguishes producing a result from earning permission to rely upon or act on it.
Knowledge traces record actual computational participation rather than merely plausible rationale.
Selective explicitness keeps Knowledge Native systems practical as neural reasoning continues to improve.
The central abstraction is over heterogeneous knowledge computation.

Discussion Questions

How does treating understanding as runtime state change the formulation of an AI problem?
Why is knowledge representation a computational decision rather than merely a storage decision?
How does a knowledge-bearing value differ from an ordinary typed value?
What is the difference between knowledge and computational expertise?
Why might a foundation model be the correct computational expert for one part of a problem but not another?
How do ACTIVATE, APPLY, ABSORB, and AUTHORIZE differ from ordinary workflow steps?
Why should a predictor's output, planner's output, and verifier's output have different epistemic status?
How do knowledge dependencies support incremental revision?
How can a knowledge gap become a computational requirement?
What is computational authority, and how is it different from confidence?
Why is a model-generated rationale not necessarily a knowledge trace?
How should a Knowledge Runtime complement rather than replace a multi-agent or workflow system?
What knowledge should remain implicit inside models, and what should become explicit?

Exercises

Choose a familiar AI application. First describe it conventionally in terms of models, data, tools, and outputs. Then reformulate it in terms of current understanding, knowledge, computational expertise, activation, absorption, and authority.
Convert three ordinary program values into knowledge-bearing values. For each, identify which contextual fields are computationally necessary.
Identify three computations in an application that a foundation model can reasonably perform and three that would benefit from specialized computational expertise. Explain why.
Construct one complete A4 cycle. Show what knowledge is present before ACTIVATE, what expertise is used in APPLY, what new understanding results from ABSORB, and what changes at AUTHORIZE.
Construct a small dependency graph for a clinical, operational, scientific, engineering, or financial application. Show how one changed observation propagates to at least two downstream results.
Describe a knowledge gap that should trigger a question, retrieval, prediction, simulation, or verification rather than a default assumption.
Choose one consequential recommendation or action and specify which expertise may propose it, what evidence must exist, what additional computation is required, and when AUTHORIZE should permit it.
Sketch an architecture containing a foundation model, one specialized computational expert, a verifier, and an orchestration framework. Separate the responsibilities of the Knowledge Runtime from those of the execution infrastructure.
Choose five kinds of knowledge in an application. Decide which should remain embodied in a model, which should remain ordinary data, which should become explicit knowledge, and which should participate in an authority condition.