The Architecture of Reliable Intelligence: From Epistemic Decisions to Governed Evaluation and Computational Sovereignty

The Architecture of Reliable Intelligence: From Epistemic Decisions to Governed Evaluation and Computational Sovereignty

1. Introduction: Intelligence Is Not Reliability

The rapid development of artificial intelligence has created an increasingly misleading association between capability and reliability. Models demonstrate stronger reasoning, larger context windows, more sophisticated tool use, and increasingly impressive performance across specialized domains. Yet these improvements do not necessarily translate into systems that can be trusted to operate independently.

A model can produce a convincing answer without possessing the necessary information. An agent can execute a technically correct operation without having the authority to do so. A system can perform well on a benchmark while failing under realistic deployment conditions. Even when a model demonstrates genuine competence, the economics and infrastructure required to operate it can introduce dependencies that undermine its practical independence.

These are not isolated problems. They are manifestations of a deeper architectural issue.

Reliable intelligence requires more than a capable inference engine. It requires mechanisms that determine what the system knows, when it must acquire additional information, when human judgment is necessary, what evidence supports its conclusions, whether its outputs satisfy meaningful evaluation criteria, and under what conditions it is permitted to act.

Three areas of recent research illuminate this problem from different directions:

1. Agent decision-making: How systems decide when to search, when to ask for clarification, and how to judge their own outputs.
2. Evaluation methodology: How benchmarks measure capability, expose failure modes, and distinguish theoretical competence from empirical and operational reliability.
3. Computational infrastructure: How hardware, model optimization, and local inference determine whether intelligent systems can operate economically and independently.

Together, these developments suggest a broader principle: intelligence should be treated as a component within a governed computational system, not as an authority in itself.

2. The First Reliability Boundary: Knowing When to Know More

An autonomous agent repeatedly encounters a fundamental epistemic problem: it must decide whether its existing information is sufficient to answer a question or perform a task.

This decision is deceptively important. Models are trained to generate plausible continuations, but plausibility is not evidence of knowledge. An agent that cannot distinguish between information it already possesses and information it must acquire will systematically produce unsupported conclusions.

Three recent research directions examine this problem.

2.1 Search as a Decision Policy

The research presented in Confident Fools or Careful Searchers? (arXiv:2610.41124) investigates whether language models can distinguish questions answerable from internal knowledge from those requiring external information.

Its benchmark contains 400 questions combining inside-knowledge and outside-knowledge scenarios, with an abstention option. It evaluates five commercial language models using action-level measures, including the Need to Search (NAS) and Knowledge Is Sufficient (KIS) dimensions.

The important distinction is that searching is not inherently good, and avoiding search is not inherently efficient.

A system that searches for every question wastes resources and introduces unnecessary external dependencies. A system that rarely searches risks answering questions using outdated, incomplete, or nonexistent knowledge.

The correct behavior is conditional.

The agent must estimate whether its available knowledge is sufficient, determine whether external information would materially improve its answer, and select an appropriate action.

This transforms retrieval from a tool-use capability into an explicit decision policy.

The architectural implication is significant: a model should not be solely responsible for deciding whether its own knowledge is sufficient. That decision can be evaluated independently through observable actions and outcomes.

2.2 Clarification as an Allocation of Human Attention

The second study, When Should AI Agents Ask? (arXiv:2610.41129), addresses another limitation of autonomous systems: ambiguity.

Agents frequently encounter tasks with unresolved requirements. Some ambiguities are inconsequential. Others fundamentally change the correct action.

Asking a human to clarify every uncertainty is inefficient. Proceeding without clarification can be dangerous or produce unusable results.

The research approaches clarification as a resource-allocation problem. Its dynamic-programming model and Pairwise Coordination Policy (PCP) coordinate clarification decisions across multiple agents competing for limited human attention.

The reported results show cost reductions of 18–31% compared with standard clarification rules. PCP is also optimal under conditions where no more than two requirements remain unresolved.

This introduces a useful distinction between uncertainty and consequential uncertainty.

An agent does not need human intervention merely because it lacks complete information. It needs intervention when the unresolved information materially affects the validity, authorization, or consequences of its next action.

This is particularly important in multi-agent environments. If several agents independently escalate every uncertainty, the human operator becomes a bottleneck. A coordinated clarification policy allows the system to prioritize questions according to their expected value.

Human attention becomes a managed computational resource.

2.3 Judgment as an Independently Evaluated Capability

The third study, Counterfactual Pairwise Augmentation (arXiv:2610.41149), examines the reliability of automated evaluation itself.

Language models are increasingly used as judges of other model outputs. However, a judge trained on pointwise examples may fail to learn the actual decision boundary separating acceptable and unacceptable responses.

A response may contain several simultaneously varying characteristics: factual accuracy, completeness, relevance, reasoning quality, and presentation. A simple binary label does not necessarily teach a model which characteristics determine the judgment.

Counterfactual Pairwise Augmentation (CPA) addresses this problem by synthesizing alternative responses with opposite labels and presenting them as pairwise comparisons.

The reported results show an improvement of 11.8 points over the strongest zero-shot judge.

The broader implication is that evaluation requires more than collecting examples of good and bad outputs. It requires constructing comparisons that expose the distinctions responsible for those judgments.

An effective judge must learn not only what a successful response looks like, but why one response is preferable to another under controlled differences.

2.4 Three Decisions, One Reliability Boundary

Search, clarification, and judgment are tightly coupled.

• Search addresses missing external information.
• Clarification addresses unresolved requirements that need human input.
• Judgment determines whether the available information and resulting output satisfy the task.

A failure in any one of these policies can compromise the others.

An agent that searches too little may produce unsupported answers. An agent that asks too often wastes human attention. An agent that evaluates poorly may fail to recognize either problem.

The solution is to treat these as separate, measurable policies rather than implicit behaviors buried inside a single language model.

This establishes the first architectural principle:

A reliable agent must have independently evaluable policies for acquiring information, escalating uncertainty, and judging its own results.

3. The Second Reliability Boundary: Measuring What Intelligence Actually Does

Once an agent can make decisions about information and uncertainty, another problem emerges: how do we know whether those decisions are reliable?

Traditional benchmark scores are often interpreted as measurements of general intelligence. But benchmarks do not measure intelligence in the abstract. They measure performance under specific assumptions, task definitions, environmental conditions, and evaluation procedures.

The benchmark itself determines which capabilities become visible and which failures remain hidden.

Three recent benchmarks demonstrate why evaluation requires multiple complementary methodologies.

3.1 StateBench: Theoretical Limits of State Tracking

StateBench, developed by researchers at Allen Institute for AI, evaluates whether language models can maintain and retrieve information about evolving states across long documents.

Its four difficulty levels examine increasingly challenging state-tracking problems, including cases where theoretical limitations predict failures in transformer-based architectures.

Frontier models continue to struggle with the hardest cases.

This matters because maintaining state is fundamental to autonomous operation.

An agent managing a long-running task must understand not only what information has appeared in its context, but how the relevant state has changed over time.

It must distinguish:

• Previous state from current state.
• Superseded information from valid information.
• Assertions from established facts.
• Changes in requirements from changes in execution status.

A system that loses track of state can produce locally coherent but globally incorrect behavior.

StateBench illustrates the importance of theoretical evaluation: benchmarks should be designed to expose structural limitations, not simply reward performance on increasingly large collections of ordinary examples.

3.2 FrontierMat: The Difference Between Plausibility and Evidence

FrontierMat takes a different approach.

Rather than deriving tasks primarily from theoretical complexity, it draws 330 problems from real experimentalists working across aerospace, semiconductors, embodied intelligence, and nuclear fusion.

The strongest evaluated model achieves 53.7%.

One particularly important failure pattern is the tendency to endorse plausible but experimentally unobserved outcomes.

This exposes a fundamental distinction in AI reasoning.

A model can identify what should be possible according to its learned understanding of a domain without establishing that something has actually happened.

In scientific and engineering environments, these are different categories of knowledge.

A predicted result is not an experimental observation. A theoretically feasible outcome is not a demonstrated capability. A reasonable hypothesis is not a verified finding.

This is an evidentiary problem.

The ability to generate technically convincing explanations does not establish the truth of the claims within them.

FrontierMat therefore illustrates why real expert problems are necessary for evaluating models. Theoretical reasoning alone cannot establish whether a system can distinguish what is plausible from what is supported by actual evidence.

3.3 CWE-bench v2: Operational Reliability Under Reproducible Conditions

CWE-bench v2 evaluates another dimension of capability: whether models can identify and resolve real cybersecurity vulnerabilities.

Its evaluation includes 100 tasks associated with 91 CVEs, using deterministic Dockerized environments and a held-out evaluation set.

The strongest evaluated model still fails 19% of tasks on every attempt.

This is particularly revealing because cybersecurity benchmarks can evaluate more than whether an answer sounds technically correct.

They can test whether the system successfully changes the state of an actual environment.

A vulnerability is either resolved under the specified conditions or it is not. A proposed patch is not equivalent to a verified patch. A model explaining the correct remediation does not establish that its implementation works.

This introduces an operational distinction between generating an action and demonstrating that the action achieved its intended result.

It also raises an authorization question: even if an agent can identify and fix a vulnerability, should it be allowed to modify the environment independently?

Technical correctness and permission to execute are separate requirements.

3.4 Three Evaluation Philosophies

These benchmarks represent three complementary approaches to evaluating intelligence.

A comprehensive evaluation program needs all three.

Theoretical benchmarks reveal systematic limitations that may not appear in ordinary tasks.

Empirical benchmarks reveal whether capabilities transfer to problems encountered by actual practitioners.

Operational benchmarks reveal whether the system can produce correct outcomes under reproducible execution conditions.

None of these methodologies is sufficient independently.

A model can perform well on theoretical tasks while failing in practice. It can produce convincing empirical reasoning without sufficient evidence. It can complete operational tasks in a controlled environment while remaining unreliable when requirements change or human authorization is necessary.

There is also a fourth requirement that these benchmarks do not directly establish: monitorability.

A system must make its internal decisions, external dependencies, state transitions, and failures sufficiently observable that another component can inspect and audit its behavior.

3.5 Benchmarks Are Architectural Specifications

The deeper lesson is that benchmarks do not merely measure existing capabilities. They influence the capabilities that developers prioritize.

If evaluation rewards answer generation, systems will optimize answer generation.

If evaluation rewards successful tool execution, systems will optimize execution.

If evaluation rewards evidence preservation, uncertainty calibration, and correct escalation, systems will have stronger incentives to develop those properties.

This means benchmark design is itself a governance decision.

The choice of what to measure determines which failures are visible, which improvements are rewarded, and which forms of reliability remain neglected.

A serious evaluation architecture must measure not only what an agent can accomplish, but also how it reaches its conclusions, what evidence supports them, and whether it respects the conditions under which its actions are permitted.

4. The Third Reliability Boundary: Owning the Computational Infrastructure

Even a well-designed agent with strong evaluation mechanisms faces a practical constraint: computation costs money.

The economics of inference determine which systems can be deployed, how frequently they can operate, how much context they can process, and who controls access to their capabilities.

This makes infrastructure a fundamental component of computational sovereignty.

The question is no longer simply whether a model can run outside a hosted API. It is whether the entire system can operate economically on infrastructure under the operator's control.

Recent developments across AWS Trainium, Google TPUs, and Apple Silicon illustrate how quickly this landscape is changing.

4.1 Trainium: Cloud-Owned Compute

The TorchNeuron integration introduces native PyTorch support for AWS Trainium, including eager execution, torch.compile, and distributed APIs.

This reduces the distance between conventional PyTorch development and execution on specialized AWS accelerators.

A Hugging Face Space also catalogs model compatibility with Trainium, including sharding, compilation time, and peak memory requirements.

Trainium represents an important distinction in the economics of owned compute.

An organization can own and control its software stack without physically owning the hardware.

Cloud-hosted accelerators can provide dedicated computational capacity while reducing the operational complexity of maintaining physical infrastructure.

However, this is not equivalent to complete computational sovereignty.

The operator still depends on the cloud provider's hardware availability, pricing, infrastructure policies, and continued service.

Trainium therefore represents a form of infrastructure control that exists between fully managed API access and personally owned hardware.

4.2 TPUs: Specialized Research and Distributed Computation

TorchTPU introduces another development in native accelerator support.

Its PyTorch integration includes Pallas-based kernels, torch.compile, distributed sharding, and a simplified device configuration through device_map="tpu".

Historically, specialized hardware often required developers to adopt different execution environments or adapt existing applications to hardware-specific frameworks.

Reducing that fragmentation makes accelerator hardware more accessible to conventional model-development workflows.

TPUs are particularly relevant to research and large-scale computational workloads where specialized hardware and distributed execution can provide substantial advantages.

The important development is not simply faster hardware.

It is the reduction of engineering overhead required to use that hardware.

A more portable software interface allows developers to select computational infrastructure according to the requirements of their workload rather than the limitations of their existing software stack.

4.3 Apple Silicon: Personal and Edge Inference

Apple Silicon occupies a different position.

PyTorch 2.15's reported MPS improvements include FP8 tensor support and Metal kernels for linear algebra, softmax, and convolutions.

The reported performance improvements include 5–6.5x faster decoding on M3 Ultra configurations.

These developments matter because personal hardware changes the relationship between inference cost and usage.

A hosted API typically charges according to consumption or subscription. A locally operated model runs against hardware that the user already owns, shifting the economic calculation toward initial hardware acquisition, electricity, maintenance, and opportunity cost.

For individual developers and small research environments, this can be transformative.

Local inference also provides greater control over data, execution environments, model selection, and system behavior.

However, local inference is not automatically cheaper or faster. Memory capacity, model size, quantization, workload intensity, and hardware utilization all matter.

The relevant question is whether a particular workload can be executed more economically and reliably on available hardware than through a hosted alternative.

4.4 Reducing the Cost of the Model Itself

Hardware is only one part of the inference equation.

Two additional developments illustrate how software-level optimization can reduce computational requirements.

VocabX explores vocabulary specialization around token cost, reporting inference cost reductions of up to 77% without changing the underlying base model.

The broader concept is that model efficiency can be improved by optimizing the representation and processing of information, not simply by purchasing faster accelerators.

Granite Switch 4.1.1 introduces modular, cache-efficient adapters that support incremental model updates.

This addresses another important inefficiency: repeatedly modifying or redeploying an entire model when only a limited portion of its behavior needs to change.

Modular adapters can make updates more manageable and reduce unnecessary computation and deployment overhead.

Together, these developments suggest that inference economics should be approached as a systems problem involving hardware selection, model architecture, vocabulary, caching, and update strategies.

4.5 Computational Sovereignty Is an Economic Decision

The economics of local inference are more complicated than comparing the purchase price of a GPU against an API subscription.

A meaningful comparison must include:

• Hardware acquisition and depreciation.
• Electricity and cooling.
• Memory capacity and model compatibility.
• Inference throughput and latency.
• Model quantization and accuracy tradeoffs.
• Engineering and maintenance costs.
• API pricing and usage limits.
• Data control and infrastructure dependencies.
• Hardware utilization across multiple workloads.

For a low-volume user, hosted inference may remain cheaper.

For a continuously operating agent, a frequently used local model may become economically advantageous.

For an organization with substantial workloads, dedicated accelerators may offer a better cost structure than repeatedly paying for hosted inference.

There is no universal crossover point.

It depends on workload characteristics, utilization, model requirements, and the actual cost of maintaining the infrastructure.

But the strategic implication is clear: the ability to operate intelligence independently is increasingly determined by control over the computational resources required to sustain it.

5. The Unified Architecture: Four Dimensions of Reliable Intelligence

The three research areas can be combined into a broader framework for understanding reliable autonomous systems.

A useful architecture distinguishes four dimensions:

5.1 Epistemic Integrity: What Does the System Know?

Epistemic integrity concerns the relationship between a system's claims and its available information.

It includes:

• Knowing when internal knowledge is sufficient.
• Recognizing when external retrieval is necessary.
• Distinguishing facts from predictions and hypotheses.
• Preserving state across long-running tasks.
• Representing uncertainty rather than concealing it.

Search-policy research and StateBench illuminate different aspects of this dimension.

The central requirement is that the system must not confuse its ability to generate an answer with evidence that the answer is correct.

5.2 Authorization Integrity: What Is the System Permitted to Do?

Authorization integrity concerns the boundaries between proposing, deciding, and executing actions.

It includes:

• Identifying when human clarification is necessary.
• Distinguishing technical capability from permission.
• Enforcing explicit execution constraints.
• Maintaining separation between recommendations and authorized operations.
• Preventing an agent from treating its own confidence as sufficient authority.

Clarification research and operational security benchmarks expose different parts of this problem.

A system may know exactly what action would solve a problem and still lack permission to perform it.

That distinction becomes increasingly important as agents gain access to filesystems, financial systems, software repositories, infrastructure, and external services.

5.3 Evidentiary Integrity: What Supports the Conclusion?

Evidentiary integrity concerns whether conclusions and actions can be justified through inspectable evidence.

It includes:

• Evaluating claims against source material.
• Distinguishing observed outcomes from plausible explanations.
• Comparing alternative conclusions.
• Preserving provenance.
• Verifying that actions actually produced their intended results.

FrontierMat and CPA illustrate why this dimension cannot be reduced to conventional answer scoring.

A system needs mechanisms that establish not merely whether an output appears reasonable, but whether its supporting evidence is sufficient.

5.4 Monitorability: Can the System Be Inspected?

Monitorability concerns whether the behavior of the system can be observed, reconstructed, and audited.

It includes:

• Recording search decisions.
• Preserving clarification requests and responses.
• Logging state transitions.
• Tracking model and tool versions.
• Recording evidence associated with conclusions.
• Verifying execution results.
• Making failures and deviations observable.

This is the dimension that connects the other three.

A system may have good epistemic, authorization, and evidentiary policies, but without monitorability there is no reliable way to establish whether those policies were followed.

Monitorability converts internal intentions into externally inspectable behavior.

6. From Capable Models to Governed Systems

These four dimensions suggest an important architectural separation.

The model should be responsible for generating proposals, interpreting information, reasoning about alternatives, and assisting with complex decisions.

It should not be the sole authority responsible for determining whether its knowledge is sufficient, whether an action is permitted, or whether its own conclusions are valid.

Those responsibilities can be distributed across independently inspectable components.

A conceptual architecture might look like this:

The architecture is deliberately heterogeneous.

Some components require probabilistic reasoning. Others benefit from deterministic rules, explicit schemas, reproducible execution, or independently verifiable records.

There is no reason to assume that every part of an intelligent system should be implemented using the same model or even the same computational paradigm.

In fact, the strongest architecture may be one in which probabilistic intelligence operates inside deterministic boundaries.

The model can propose an action. An independent policy can evaluate whether the action is permitted. A separate execution layer can carry it out. An evidence layer can record what happened, and an evaluator can determine whether the result satisfies the original requirements.

This creates multiple opportunities to detect failures before they become consequential.

7. The Economics of Reliability

There is another important connection between these research areas.

Every reliability mechanism has a cost.

Searching consumes time and computational resources. Asking humans consumes attention. Evaluation requires additional inference or execution. Evidence preservation requires storage and processing. Monitoring introduces infrastructure overhead.

Similarly, running increasingly capable models locally requires hardware, memory, and energy.

The goal cannot be to maximize every safeguard without considering its cost.

Instead, the system must allocate resources according to the expected consequences of failure.

For example:

• A low-risk factual question may require no external search if the model has sufficient knowledge.
• A time-sensitive factual claim may justify retrieval and source verification.
• An ambiguous formatting preference may not justify interrupting a human.
• An irreversible financial or infrastructure operation may require explicit authorization.
• A cybersecurity modification may require independent testing before deployment.
• A frequently used local agent may justify dedicated hardware if utilization makes it economical.

This suggests that reliability should be optimized as a resource-allocation problem.

The appropriate level of verification, clarification, monitoring, and computational expenditure depends on the task's uncertainty, potential impact, reversibility, and cost of failure.

A reliable system is not one that asks for permission constantly, searches endlessly, or verifies every trivial operation.

It is one that knows where additional safeguards produce meaningful improvements.

8. Open Research Questions

Combining these developments reveals several research questions that deserve greater attention.

8.1 Can Search, Clarification, and Evaluation Be Composed?

Current research examines these policies independently.

But an operational agent needs to coordinate them.

When should an agent search before asking a human? When should an independent evaluator request additional evidence? Can the system estimate the value of another search against the cost of human intervention?

A unified decision policy could allocate resources across these actions rather than treating them as independent tool choices.

8.2 Can Benchmarks Evaluate the Entire Reliability Lifecycle?

Most benchmarks evaluate isolated capabilities.

A more comprehensive benchmark would follow an agent through an entire task:

1. Interpret the original requirements.
2. Identify missing information.
3. Decide whether to search.
4. Request clarification when necessary.
5. Develop a proposed solution.
6. Connect its conclusions to evidence.
7. Obtain appropriate authorization.
8. Execute the permitted action.
9. Verify the result.
10. Preserve an auditable record.

Such a benchmark would measure reliability as a process rather than a collection of disconnected scores.

8.3 Can Reliability Be Measured Independently of Model Intelligence?

As models become more capable, it becomes increasingly important to distinguish improvements in reasoning from improvements in governance.

A more capable model may perform better on a task without becoming better at recognizing when it should abstain, ask for help, or defer to an external authority.

Evaluation should therefore measure both task performance and policy compliance.

The objective is not merely to determine whether a model can solve a problem, but whether the surrounding system consistently determines when and how that capability should be used.

8.4 What Is the Economic Optimum for Governed Local Inference?

The development of Trainium, TPUs, and Apple Silicon creates more deployment options, but the cost of running a complete governed agent remains poorly understood.

The relevant calculation should include not only model inference, but also retrieval, independent evaluation, monitoring, storage, and execution.

A small local model performing routine coordination, combined with a more capable model for difficult reasoning and deterministic infrastructure for authorization, may prove more economical than running every operation through a single large model.

This raises the possibility of a new optimization target: the lowest total cost of reliable task completion rather than the lowest cost per generated token.

8.5 Can Monitorability Become a Standard Evaluation Requirement?

A system should not receive a high reliability rating merely because it produces correct answers in a benchmark.

It should also demonstrate that its decisions can be reconstructed and that its actions can be verified.

Future benchmarks could explicitly measure provenance completeness, state consistency, authorization compliance, and auditability.

This would move observability from an optional engineering feature to a measurable property of intelligent systems.

9. Conclusion: Intelligence Requires Boundaries

The developments examined here point toward a broader understanding of artificial intelligence.

Search-policy research demonstrates that systems must know when their internal information is insufficient.

Clarification research demonstrates that human attention is a limited resource that autonomous systems must allocate intelligently.

Counterfactual evaluation research demonstrates that judging model outputs is itself a technical problem requiring carefully constructed evidence.

StateBench, FrontierMat, and CWE-bench demonstrate that theoretical capability, empirical performance, and operational success are different things.

Developments in Trainium, TPUs, Apple Silicon, vocabulary specialization, and modular adapters demonstrate that computational independence depends on more than model availability. It requires an economically viable infrastructure capable of sustaining intelligent operations.

These are not separate developments. They describe different layers of the same engineering problem.

A capable model can generate possibilities. A reliable system must determine which possibilities are supported by evidence, which actions are permitted, and whether the resulting outcomes can be verified.

The distinction becomes especially important as AI systems move from generating text to controlling software, infrastructure, information pipelines, and real-world processes.

The future of AI will not be determined exclusively by which model has the strongest reasoning capabilities or the largest parameter count.

It will also be determined by who can build systems that preserve evidence, constrain authority, maintain state, allocate uncertainty, and operate independently.

Intelligence generates possibilities. Architecture determines which possibilities become authorized, verifiable outcomes.

That is the difference between a model that appears intelligent and a system that can be trusted to act.

References and Further Reading

Agent decision-making and evaluation

• Confident Fools or Careful Searchers? — arXiv:2610.41124.
• When Should AI Agents Ask? — arXiv:2610.41129.
• Counterfactual Pairwise Augmentation — arXiv:2610.41149.

Benchmarking and evaluation

• StateBench — Allen Institute for AI, long-document state-tracking evaluation (dataset and code on Hugging Face).
• FrontierMat — Evaluation of AI capabilities on real-world materials research problems.
• CWE-bench v2 — Collinear AI, reproducible cybersecurity vulnerability evaluation (dataset on Hugging Face).

Computational infrastructure

• TorchNeuron — Native PyTorch support for AWS Trainium (open-source backend; GitHub).
• TorchTPU — Native PyTorch support for TPU accelerators (open-source backend; GitHub).
• PyTorch 2.15 MPS — Apple Silicon acceleration and Metal kernel improvements.
• VocabX — Dharma AI, vocabulary specialization and inference-cost optimization (77% measured cost reduction).
• Granite Switch 4.1.1 — Modular adapters and cache-efficient model updates.

Related conceptual foundations

• Daniel Kliewer — The Boundaries of Intelligence.
• Daniel Kliewer — Computational Sovereignty.