This appendix organizes the meaning and boundaries of the terms used in this book. If you want the general meaning of a term, see Appendix A, "Basic AI Terminology." Here, we cover this book's specific usage, and the distinctions that keep it from being confused.
B.1 Boundaries Around AI, Model, and Context
Artificial Intelligence (AI)
In this book, we treat AI as a broad term that includes mechanisms and services that perform intelligent processing. AI is not a word that means only LLM.
Machine Learning
Machine learning is a term for methods that learn regularities or relationships from data. It's treated as an important idea related to AI, but we don't treat AI and machine learning as the same thing. We also don't treat AI's history as one method completely replacing the previous one in a simple sequence.
Model
A model is a term for a trained mechanism that performs processing or produces output in response to input. We distinguish a model from the AI service or application it's built into. We don't decide the configuration of the whole service just from looking at the model.
Language Model
A language model is a model that handles sequences or relationships of language. We treat language model and LLM as related terms, but we don't take the term language model to automatically refer only to an LLM.
Large Language Model (LLM)
LLM is short for Large Language Model — a large-scale language model. We don't treat LLM as the same thing as AI as a whole. We also distinguish the group of models called LLM from the AI service as a whole.
AI Service
An AI service may be offered by combining, in addition to processing via a model, multiple functions — such as input handling, a screen, search, and external tools. We don't treat an AI service as a single model itself. We don't assume anything about undisclosed internal configuration unless we have confirmable Evidence.
Transformer
Transformer is an architecture treated as one way of building a model. We don't treat Transformer, LLM, and AI service as the same term. We also don't take its history to imply a simple sequence of replacement.
Architecture
Architecture is a term for thinking about the elements that make up a mechanism and the relationships between them. This book's conceptual diagrams exist to organize relationships — they do not show undisclosed vendor internal implementations or processing order.
Output
Output is the result returned by an AI service or model. We treat output, first, as information subject to confirmation — not as the same thing as an external fact or independent Evidence. An AI's output report alone does not confirm that a search or a test was actually executed.
Context
Context is a term related to information used in the current processing or interaction. We do not treat context, saved information, and state incorporated through training as the same thing. Exactly what information is used, and how, may not be knowable without public Evidence.
Current context (information currently available in this conversation or task) is treated as a subordinate description under context. Something discussed or saved in the past is not the same as being currently available.
Saved / Persistent Information
Saved information refers to information left behind by a feature when a service officially provides a save or memory function. We distinguish saved information from the current context and the trained model's state. We don't assume anything about how it's stored, how long it's retained, or how it's internally handled, unless we have public Evidence.
Learned Model State
Learned model state is a term this book uses to describe the state incorporated into a model through training. We don't treat it as the same thing as the current context or saved information. We can't assume that a provider's internal state, or its specific implementation, is visible to a user.
B.2 Evidence, Source of Truth, and Confirmation
Claim
A Claim is an assertion or a statement about completion that this book treats as subject to confirmation. For a Claim, we separately consider what it's saying, what scope it covers, and what needs to be checked. We don't treat this book's confirmation vocabulary as a universal rule automatically applicable to every development setting.
Completion Assertion
A completion assertion is a statement conveying that something is done — such as "it's finished," "I confirmed it," or "it returned PASS." We distinguish a completion assertion from an actually observable change or execution result. The existence of a report alone does not prove that the object is complete or that an external operation was executed.
Evidence
Evidence is the grounds or observation results used to confirm a Claim. In this book, we consider how far something can be confirmed, in light of the object, the method, the scope, and the conditions. AI-generated text, strongly confident wording, agreement among multiple AIs, or a generated citation, by themselves, do not become Evidence that independently confirms an external fact.
Source of Truth
A Source of Truth is an information source chosen as the standard for confirmation, for a given question or Claim. Depending on what you want to know, the appropriate source of confirmation varies — a specification, a file in the repository, Git state, a test result, a CI result, a configuration, a runtime observation, a log, and so on. There is no single, universal Source of Truth, and an AI does not get to decide its own confirmation source and gain authority over it.
VERIFIED / OBSERVED
VERIFIED / OBSERVED represents something directly confirmed through a confirmable, authoritative source, or through a reproducible observation. In this book, we don't place speculation or an AI's report into this classification beyond what has been directly confirmed.
INFERENCE
INFERENCE is an interpretation or conclusion drawn from confirmed Evidence, where that Evidence does not directly demonstrate the final statement. INFERENCE is not a baseless guess, but it also differs from a directly observed fact. We keep track both of the fact that something is an inference and of its grounds and scope.
UNKNOWN / UNDISCLOSED
UNKNOWN / UNDISCLOSED represents something that cannot be confirmed from the available Evidence, or that has not been made public. In this book, we don't fill in what's unknown with a plausible guess. UNKNOWN is not FAIL, and being UNKNOWN is also not PASS.
PASS
PASS is a scoped result representing that a specified confirmation outcome was observed, for a specified target, under specified conditions. When reading PASS, we check it together with at least the target, version, test set, conditions, and observation point. PASS does not mean that the system as a whole is correct, that it is safe, that it has been approved for production use, or that UNKNOWN has been reduced to zero.
FAIL
FAIL represents that, against specified confirmation conditions, the confirmed result did not meet the criteria. FAIL is different from UNKNOWN. We don't lump together, as the same kind of failure, a FAIL where there is a confirmable discrepancy and an UNKNOWN where confirmation material is simply insufficient. FAIL also does not mean the failure of the project as a whole.
Verification Loop
The Verification Loop is the minimal confirmation flow used in this book. It is not a universal SDLC or industry standard — it's this book's model for keeping an AI's output and the state of its target separate.
- Understand the request and fix intent, scope, and constraints.
- Receive the AI-generated output.
- Identify material Claims or completion assertions in that output.
- Specify the relevant Source of Truth and expected observable result.
- Obtain and inspect independent Evidence against the intent and constraints.
- Classify the Evidence, including explicit UNKNOWN where support is insufficient.
- Human decides whether to accept, correct, stop, or escalate; record the decision and return to step 1 only when another bounded iteration is justified.
Technical Verification
Technical verification is examining whether an object satisfies specified conditions or an expected result. We keep technical verification separate from a human deciding the next action. A technical PASS alone does not automatically authorize the next protected operation or a release.
Verification
Verification is a broad term for examining a result by making the object, criteria, method, and conditions explicit. In this book, we relate general verification, technical verification, and the Verification Loop to one another, but we don't collapse them into a single, identical state.
B.3 Human Authority, Scope, and Iteration
Human Authority
Human authority is the higher-level idea of who ultimately holds the power to decide on important judgments or operations. In this book, we do not treat an AI's capability, Human approval, and Human authorization as the same thing. The scope of Human authority is decided by the project or the Human.
Human Approval
Human approval is a human's decision — having taken confirmed material into account — to accept, correct, stop, or escalate. Human authorization is a human's decision that a specific scope or operation may be executed. The two are related, but they are not necessarily the same decision. Human approval does not strengthen Evidence or itself amount to technical verification, and a technical PASS does not automatically authorize an operation requiring further permission.
Human Authorization
Human authorization is a human's decision that a specific scope or operation may be executed. Having authorization does not prove technical correctness, and it does not arise automatically from an AI's capability or a technical PASS.
Intent
Intent is what the Human is trying to accomplish with the current request or task. Intent is related to scope and constraints, but it is neither scope itself nor constraints themselves. Also, merely stating an intent does not authorize out-of-scope operations or additional permissions.
Scope
Scope is the boundary of what's covered by a given request or check. In this book, we use it to separate what's intended from what's out of scope. Deciding a scope does not automatically authorize out-of-scope work or permissions.
Constraints
Constraints are the conditions or limits attached to a piece of work or a check. Confirming intent, scope, and constraints in advance keeps an AI's proposal from expanding beyond the intended object. As used in this book, this does not define a complete requirements process or project-management method.
Observable Result
An observable result is a result that can be confirmed with a decided criterion and method. The result is not necessarily numerical — it's observed in whatever form fits the question, whether that's file content, a test result, a configuration, or a runtime state. We don't treat something as having been observed when it hasn't actually been observable.
Escalation
Escalation is stopping and asking a human or an appropriate decision-maker to weigh in, for a problem that exceeds the current scope or the authority available to decide it. In this book, we don't fix escalation as one particular organizational structure or a universal procedure.
Iteration / Next Attempt
Iteration, or a next attempt, is trying again — clarifying the reason and scope — to address a discrepancy or shortfall found during confirmation. It is not automatically repeating until it PASSes, over and over. Whether to make a next attempt is a judgment the human makes based on the situation and the risk.
B.4 Completion States
This book treats the following six completion-related states separately. Reaching one state does not automatically imply a later state or a separate permission.
implemented
implemented is the state in which an intended change has been implemented. Having implemented something is separate from having tested it, having it PASS, having committed it, having pushed it, and having deployed it.
tested
tested is the state in which a specified test has been run. Having tested something does not mean that the whole is correct, or that it is PASS, beyond the scope the test actually confirmed.
PASS
PASS is the state in which a confirmation result met the criteria, for a specified scope. For the detailed boundary, see the "PASS" entry in B.2, which covers target, version, test set, conditions, and observation point.
committed
committed is the state in which a change has been recorded as a commit in the repository. Having committed something is separate from having pushed it to the remote, and from having deployed it.
pushed
pushed is the state in which a commit or other change has been sent to the remote repository. Having pushed something does not mean it has been deployed to the target environment, that it is technically safe, or that release has been approved.
deployed
deployed is the state in which a change has been placed into the target execution environment. In this book, we distinguish having deployed something from implemented, tested, PASS, committed, and pushed. We don't infer safety, or approval for the next operation, from the fact of deployment alone.
confirmed
confirmed is a description meaning that some form of confirmation has taken place. In this book, we do not treat confirmed as a seventh completion state added to implemented, tested, PASS, committed, pushed, and deployed. We separately check what was confirmed, and under what conditions.