Thinking About AI Through Sets and Topology From a Machine That Guesses the Right Answer to an Infrastructure for Designing the Boundaries of Decision

🎥 The YouTube version is also available:

Designing Enterprise AI with Sets and Topology | Boundaries for Knowledge, Trust, and Action

Books: What Kind of Mathematical Worldview Is AI Built Upon?: From Finite Rules to Generative Models

When we think about applying AI, we often begin with a question of predictive accuracy: How accurately can it predict?Demand forecasting, anomaly detection, candidate recommendations, customer-support responses—these all matter.

But once AI is implemented in actual business operations, another question comes to the foreground:

What evidence does this AI have right now, and how far is it permitted to proceed?

Set theory and topology offer a useful perspective for thinking about this question. The point is not to introduce difficult mathematics into business. Rather, these are useful languages for designing the objects, relationships, and boundaries that AI handles without conflating them.

1. Business AI Is, First of All, Working with Sets

A set is a collection of objects treated as a whole according to a given condition. For example, “cases with response deadlines this month,” “suppliers handling this product category,” and “sales representatives authorized by contract to offer discounts up to a certain amount” are all sets defined by conditions. Customers, cases, contracts, documents, equipment, sensor readings, employees, approvers, and AI agents can all be treated as sets in a business context.

Business decisions become difficult because they cannot be made on the basis of a single condition alone. A discount amount may appear reasonable, but the case cannot proceed if it violates the contract. Even if it is consistent with the contract, further verification is needed when supporting evidence is insufficient. Even with sufficient evidence, automatic execution is not possible if the responsible person lacks the necessary authority.

For this reason, rather than leaving the question AI must address as one large question—“Should this case be approved?”—it is useful to separate it into sets defined by individual conditions. By overlapping the sets that satisfy each condition, what remains is the set of cases that can proceed through the business process at this point in time.

Consider a discount request. Instead of beginning with “Should this discount be approved?”, we can distinguish the following sets:

• the set of cases eligible for discount consideration;
• the set of cases with comparable precedents;
• the set of cases consistent with the current contract;
• the set of cases supported by the required evidence;
• the set of cases that can be handled within the responsible person’s authority; and
• the set of cases eligible for automatic execution.

These sets do not simply replace one another in sequence. The set of cases with comparable precedents, for example, is a set of reference information. The sets of cases consistent with the contract and supported by the required evidence, on the other hand, represent conditions that must be met in order to proceed. AI compares these sets, excludes cases that do not satisfy the conditions, and makes unmet conditions visible as it narrows the candidates. An AI that finds comparable cases, one that checks policies, one that identifies missing evidence, and one that determines an approval path each construct subsets according to different conditions.

Suppose an AI proposes that “a 10% discount appears appropriate” based on past cases. This is a useful hypothesis derived from the set of comparable precedents. But it does not necessarily mean that the case also belongs to the sets defined by contract terms, required evidence, and the responsible person’s authority.

The key point is that an AI producing a plausible answer is not the same as a case belonging to the set that may legitimately proceed through the business process. The former generates a candidate judgment or hypothesis. The latter indicates that the candidate satisfies the necessary conditions of evidence, policy, and authority, and may actually be allowed to move forward.

2. The Empty Set Is Not a Failure; It Is an Important Decision Result

In mathematics, an empty set is the result of looking for objects that satisfy a given condition and finding none. For example, if no cases meet both conditions—having the required evidence and being authorized for automatic execution—the result is an empty set.

In ordinary business systems, a search result of zero is often treated simply as “no data” or as an error. But when AI is involved in business judgment or execution, that zero has a clear meaning. It means that, within the currently available evidence, policies, and authority, there is no case that can safely proceed to the next stage.

In other words, an empty set does not represent an AI failure. It represents the AI correctly indicating that no case is currently eligible to proceed, rather than filling the gap by assuming that an eligible case must exist. For example, the following situations may arise:

• No document containing the required evidence can be found.
• No person currently available has the authority to approve the transaction.
• Among the sources the AI is permitted to reference, there is no information that supports the conclusion.
• The action proposed by the AI is not included in the set of actions it is permitted to execute.

These situations do not necessarily mean that misconduct or an anomaly has been confirmed. The evidence may exist elsewhere, or an authorized person may become available later. That is precisely why the AI should not fill the gap with plausible inference. It should explicitly state: “cannot be verified,” “not authorized,” or “cannot be executed,” and transition to further verification, human approval, or a stop.

The principle of not counting Unknown as Pass rests on exactly this idea. If the set of verifiable evidence is empty, it does not mean that there is no problem. It means that the basis required to move the decision forward is missing.

3. Topology Deals with Nearness and Boundaries

Sets allow us to distinguish whether an object is included or excluded. But in practical AI, it also matters whether things are similar, close, or surrounded by related cases. This is where a topological perspective becomes useful.

Put very simply, topology is a way of thinking about which points form neighborhoods with one another and where boundaries lie, rather than about the exact distance between individual points. A map provides an intuitive example. Even without measuring the precise distance from Tokyo to Osaka, we can ask: “Which stations surround this station?”, “How far does the area connected by this rail line extend?”, or “How do jurisdiction and rules change when a prefectural boundary is crossed?” Topology concerns these patterns of connection, grouping, and boundary.

Applied to AI, each document or business case can be understood as a point on such a map. To say that meanings are “close” means that cases sharing a context or issue form a neighborhood. This closeness is not physical distance; it is semantic proximity calculated from language, content, circumstances, and relationships.

Generative AI and vector search arrange documents, images, and cases according to semantic proximity. Documents about delivery delays, component shortages, and alternative sourcing, for example, form a nearby neighborhood in semantic space. This means that AI does not merely look for the exact phrase “delivery delay.” It can explore related issues in the surrounding neighborhood, such as procurement risk, substitute parts, supplier changes, and customer impact. As a result, it can find relevant past cases even when the words do not exactly match.

However, semantic similarity does not mean that the same business decision should be made.

A past incident may closely resemble a current signal, while the safety criticality of the equipment, the freshness of the evidence, the contract terms, or the business impact of stopping operations may differ. When AI indicates that something is similar, it can identify a neighborhood worth investigating. That alone, however, does not justify automatically taking the same action.

4. Do Not Collapse Three Different Spaces into One

As we have seen, AI can identify the proximity of cases and narrow down the sets that satisfy particular conditions. But the word “near” does not have only one meaning. Two cases may be close in terms of similar content, while being far apart in terms of whether they can be trusted or which actions may be executed.

To use business AI safely, it is helpful to distinguish at least three spaces. This does not mean that three separate systems must always be built. Rather, it is a framework for viewing one case through different questions: What is it similar to?How far can it be trusted? and What may be executed?

The first, semantic space, is where AI searches for past cases and related documents. Here, similarity of wording and context has value. The next, trust space, asks whether that information can be used as evidence. Even when the content is the same, information may not constitute trustworthy evidence if its provenance is unclear, its update date is old, or it was not obtained under the required authority. Finally, execution space asks a different question: even if the evidence is sufficient, is the action permitted for the AI or responsible person? Is the scope of impact acceptable? Under what conditions must the process stop?

Many AI misuses arise when something that is close in semantic space is treated as though it were also close in trust space or execution space. In other words, the discovery of a similar case is too quickly taken to mean, “We may make the same decision on the same grounds,” or “We may automatically execute the same action.”

For example, the fact that a similar customer accepted a particular condition may be useful when preparing a sales proposal. It is a valuable neighborhood in semantic space. But it does not necessarily mean that the same condition can be offered to the current customer. Contract clauses, credit status, the authority of the responsible person, and individual commitments may differ. If the record of the past case is outdated, or the current representative lacks authority to make the offer, the two cases cannot be considered close in trust space or execution space.

In other words, a semantic neighborhood is not a neighborhood of answers. It is first a neighborhood of hypotheses that should be investigated. AI can use comparable cases as a starting point for a hypothesis, after which the reliability of the evidence and the conditions for execution must be verified. Following this order allows us to use AI’s exploratory ability without crossing operational boundaries merely because two cases appear similar.

5. AI Governance Lives at the Boundary

Each of the semantic, trust, and execution spaces introduced in the previous section has a range within which it is reasonable to say, “The process may proceed this far.” From a topological perspective, what matters especially is the edge of that range: the boundary. A boundary is not where AI suddenly loses its capability. It is where the way we treat an AI proposal should change—from directly connecting it to execution, to requiring verification, approval, or constrained execution.

Inside a well-defined area of permitted automation, AI can process work quickly and continuously. The benefits are especially significant for work that is routine and low-risk, supported by sufficient evidence, governed by clear authority, and limited to a pre-approved scope of impact. For example, a small, standard discount request that satisfies every required condition, or the temporary isolation of a general endpoint with limited operational impact, may be relatively suitable for automation under defined conditions.

As evidence, authority, or impact scope becomes uncertain, however, a case approaches the boundary. This does not necessarily mean that the conclusion itself is wrong. It means that the conditions for automatic execution are no longer sufficient. Examples include:

• Part of the required evidence cannot be obtained.
• The data is stale, but an urgent response is required.
• The proposed action is reasonable, but the required execution authority is missing.
• The same operation would affect a critical server or safety-related equipment.
• The case is close to a past precedent, but differs in one material condition.

What is needed in these situations is not to increase the AI’s confidence score slightly and allow it to cross the boundary. Even if the AI says that an action is “probably correct,” that does not automatically resolve deficiencies in authority or the scope of impact. What is needed is to make the conditions for crossing the boundary explicit. Additional evidence, another approver, a reduced scope of impact, a time-limited action, or a stop may be those conditions.

In other words, boundary design is not a binary choice between automation and non-automation. It is a design that provides multiple possible transitions according to the circumstances: automatic execution, execution with human approval, limited trials, further investigation, or a stop.

Consider ransomware containment. If the indicators of danger are sufficiently strong and the target is a general endpoint, temporary isolation may be automated. But if the same indicators appear on a core server supporting financial close, human approval may be required. Another option may be to begin not with isolation itself, but with enhanced monitoring or partial communication restrictions. This difference is not primarily a matter of detection accuracy. It is a matter of designing the boundary of the execution space, taking into account the criticality of the target and the impact of execution.

6. Decision Trace Records Transitions Between Sets

So far, we have seen how AI can find comparable cases, examine evidence, policy, authority, and impact scope in sequence, and switch processing modes at a boundary. Decision Trace is an approach to recording this entire chain of judgment—not only the final outcome, but also the transitions along the way.

From the perspective of the Decision Trace Model, a decision is not the output of a single score. Retaining only a final label such as “approved” or “rejected” does not tell us what evidence was used, which conditions were satisfied, or which conditions could not be satisfied. A decision is the process through which a candidate set is transformed into an executable set by passing through conditions related to evidence, policy, authority, time, and accountability.

Consider a discount request. First, AI identifies relevant precedents. Next, it verifies whether the referenced cases and contract documents provide sufficient grounds to be used in the current decision. It then checks whether the proposed action is consistent with the current contract and policies, and who is authorized to execute or approve it. At each stage, the set of cases is narrowed, or branches into a set requiring further verification.

This flow can be represented as follows:

Candidate set
  → Set with relevant evidence
  → Set with sufficient evidence
  → Set satisfying policy and authority
  → Executable set
  → Automatic execution / Human approval / Further verification / Stop

A Decision Trace records more than the states before and after each arrow. It connects the documents and observations used as evidence, the policies applied, the person or agent that proposed the judgment, the authority verified at that point in time, and the conditions that allowed—or prevented—the case from moving to the next state.

By recording these transitions, we can later trace why one case was not automated, who approved an exception on what evidence, or which missing evidence caused the process to stop. This is not only for audit after a problem has occurred. It also becomes material for learning what should be checked next time in similar cases, and for improving the design of policies and boundaries.

In this model, AI is not primarily the entity that delivers the conclusion. It is the entity that makes the state of each set visible, identifies evidence and gaps, and proposes the next transition. Humans define the boundaries, take responsibility for exceptions, and update the boundaries themselves when necessary. Dividing roles in this way makes it possible to use AI’s speed while preserving the legitimacy and explainability of execution.

7. A Different View of AI Applications

When we adopt this perspective, familiar AI application themes begin to look different. None of these technologies is merely a mechanism for improving accuracy or accelerating processing. Each can be understood as a mechanism for defining what may be referenced, keeping meaning, trust, and execution distinct, selecting an appropriate transition at a boundary, and recording the process.

RAG: Managing the Boundary of Referencable Knowledge

RAG is not merely a mechanism for returning the right text. First, it defines the set of knowledge that may be referenced: which documents, which versions, and under which permissions. Next, it searches that set for relevant neighborhoods and presents the evidence supporting its response. If it cannot access a relevant area or cannot find sufficient grounds for an answer, it leaves that area as Unknown rather than filling the gap with plausible language.

From this perspective, RAG quality is not determined by fluency alone. What matters is whether it can make clear which evidence set was referenced, what could not be referenced, and how far the response may be used in a business decision.

Multi-Agent Systems: Expanding the Decision Neighborhood and Handling Counter-Evidence

Multi-agent systems are not merely configurations that run many AIs. Rather than rushing to reinforce one conclusion, they examine different evidence sets, counter-evidence sets, and execution conditions in parallel. One agent may search for comparable cases, another may check policies and contracts, and yet another may search for contrary evidence or operational constraints.

This broadens the neighborhood around a decision while avoiding overreliance on similar cases alone. The important point is not to reduce the outputs of all agents to a single answer by majority vote. It is to make visible which evidence has been assembled, which counter-evidence or gaps remain, and what transition should be selected next.

Physical AI: Protecting Local Boundaries for Each Asset

Physical AI is not merely AI that automates the physical workplace. It is an architecture that distinguishes, for each piece of equipment, work area, or material flow, observable states, executable actions, local policies, and areas of responsibility. For example, being able to observe a temperature rise in a machine and being authorized to stop that machine are different permissions. Even if stopping the equipment appears appropriate from a safety perspective, it may not be appropriate to execute the stop without considering its effect on surrounding equipment or the production plan.

For this reason, Physical AI requires boundaries for semantic space, trust space, and execution space to be defined locally for each operational environment. This makes it possible to use local observation and judgment while preventing unauthorized actions or automated execution that exceeds the permitted scope of impact.

Trust Infrastructure: The Layer That Implements Boundaries and Transitions

Trust Infrastructure is the layer that implements these boundaries and transitions across the three application areas above. Identity establishes who or which agent is involved. Evidence establishes what may serve as grounds for a judgment. Policy and authority control what may be executed. Time governs the validity of authority and evidence, while accountability makes the Decision Trace traceable.

In other words, Trust Infrastructure is not merely a guardrail for restricting AI after the fact. It is the operational foundation that enables AI to explore semantic neighborhoods, make judgments using appropriate evidence, act within permitted boundaries, and transition to a human at the boundary.

Conclusion: Part of AI’s Value Is in Not Blurring Boundaries

AI is exceptionally good at finding semantic neighborhoods within ambiguous information. But a trustworthy AI for business must not treat everything that is close as though it were the same.

Which set does the case belong to? What has been verified, and what remains unverified? Up to which boundary may the process proceed automatically, and from where must a person take responsibility? These conditions should be designed and recorded as decision transitions.

AI is not merely a technology for predicting the right answer.
It is a technology for handling how far we may proceed, here and now,
in a space where meaning, evidence, authority, time, and accountability intersect.

Sets and topology provide a quiet but powerful language for designing that syst

Chinoba

Chinoba

Intelligence as Relationship

Research Platform

founded by

Masao Watanabe

AI Systems Architecture
Decision Trace
Human–AI Coordination
Algorithmic Governance