Start with what's visible
When using an AI service, what is most clearly visible to a user is the following flow:
But as we saw in Chapter 1, an AI service and a model are not necessarily the same thing. So in this chapter, rather than guessing what must be happening internally, we look at an AI service from the perspective of what can be confirmed from the outside.
What a user can observe directly
At minimum, the input a user gives to a service, and the output returned by the service, are things the user themself can observe. For example:
can be directly confirmed. On the other hand, what happened between those two is not visible in the same way. If a public API or documentation exists, you may be able to confirm more about the structure of the input/output, among other things. Public information can change with the product or version, though, so we do not automatically assume "it was that way before, so it's still that way now."
Not necessarily only generation
In an AI service, functions other than model-based Generation can be involved in the output. For example:
- Search
- Retrieval
- external tools
The details of what Search, Retrieval, and Tools mean and how they differ are covered in later chapters.
In this chapter, we confirm just this one point:
AI services also exist where elements other than model-based generation are involved.
Separating conceptual diagrams from actual internal structure
Teaching materials sometimes use a diagram like the following to aid understanding:
The ? in this diagram is important. It expresses that whether Search, Retrieval, or Tools are actually involved cannot always be confirmed from the outside.
When you can confirm external access
Depending on the AI service, a user may be able to confirm a record or display related to the use of Search or Tools. For example, an artifact showing that external information was accessed may be distinguished from the final generated text. If such a record exists, it becomes a basis for judging that "there is observable information about external access in this interaction." However, an AI writing "I searched" and there being an externally confirmable artifact of that search are not the same thing.
This distinction becomes very important in the later chapter on Verification.
Appearance alone cannot fix a single internal structure
Just from the input and output visible to a user, you may not be able to pin down the undisclosed structure of the backend to a single account. Two services that return similar outputs are not necessarily built on the same internal structure. A publicly disclosed architecture, or documented API behavior, can serve as confirmation material within the scope it's publicly disclosed. On the other hand, without Evidence, we don't decide "it's probably like this" about things such as:
- prompt assembly
- routing
- storage
- internal model selection
We treat such parts as UNKNOWN / UNDISCLOSED in this book.
UNKNOWN is not a failure
UNKNOWN / UNDISCLOSED does not mean "a hole that still needs to be filled with an invented explanation." Rather, it marks a boundary: this much can be confirmed, and beyond this point it cannot. Leaving what's unknown as unknown is important in confirmation work. Adding a plausible guess makes it unclear where confirmed fact ends and imagination begins.
Thinking through four usage patterns
For understanding's sake, let's split the use of an AI service into four patterns.
| Pattern | What the user can confirm | What may remain unconfirmable |
|---|---|---|
| Simple generation | input / output | undisclosed internal processing |
| When Search is involved | input / output, and possibly a Search artifact | actual search method, undisclosed internal processing |
| When Retrieval is involved | input / output, and possibly an artifact showing retrieval | scope of retrieval, undisclosed processing |
| When an external tool is involved | input / output, and possibly an artifact showing tool use | internal handling of the tool call, etc. |
These four are a practice organization for thinking about what can be confirmed from the outside and what may remain unconfirmable — not a formal taxonomy that classifies AI services into four types.
Confirming a result separately from an AI's explanation
In AI-assisted development, you can sometimes confirm the result of a piece of work through a separate method, rather than just looking at the output. For example, when an AI reports:
"I modified the file"
"The tests returned PASS"
"I searched the web"
that report and the actual file, test results, or search artifact are separate objects. This chapter does not yet go into the details of Verification. For now, just remember the distinction:
An AI's explanation and a result confirmed by a separate method are not the same thing.
Chapter summary
This chapter looked at an AI service not by guessing at its internal structure, but from the range of what can be confirmed from the outside. The important points are:
- a user can at minimum observe their own input and the returned output
- if a public API or documentation exists, more can sometimes be confirmed
- an AI service can involve Search, Retrieval, or Tools in addition to Generation
- a concept diagram is not treated as the actual internal architecture of a vendor
- an AI's own self-report is distinguished from an externally confirmable artifact
- backend internals with no public Evidence are left as
UNKNOWN / UNDISCLOSED - UNKNOWN is not a failure to be filled with guesses — it is the boundary of what can be confirmed
- generated output and an independently confirmable result are not the same thing
The next chapter shifts perspective from the AI service as a whole to the model, and looks at how a model generates output from input — from the standpoint of Tokens, numerical representations, Transformers, and next-token generation.