Reason About Tokens, Attention, and Generation

Mechanism knowledge has one job here

The completed MD-01 dossier tells us what Mosaic Desk may propose, how that behavior will be judged, and who retains authority. It includes English, Gujarati, and code-switched cases; it requires evidence references; it names uncertainty, abstention, escalation, degradation, and prohibited effects.

We have not selected a model or access posture. Before comparing candidates, we need enough mechanism knowledge to ask better engineering questions.

This chapter does not try to turn an application engineer into a model researcher. It does not derive the Transformer, survey every architecture, or explain why a model produced one particular sentence. It builds a bounded chain from text to observed output so that we can predict failure surfaces and design tests.

The chain is:

text and messages -> tokenizer and template -> token representations and positions -> attention-based layers -> next-token scores -> decoding -> response

Each arrow is conditional on the actual model and runtime. Modern systems add mechanisms and variations not shown here. The chain remains useful because it stops several common mistakes:

• characters, words, and tokens are not interchangeable;
• a context window is not a guarantee that every included fact will influence the output reliably;
• attention is a computation, not a complete explanation of a response;
• a next-token probability is not a probability that a statement is true;
• decoding settings and chat templates are behavior-facing configuration;
• repeated fluent outputs do not establish dependable system behavior.

Mechanism knowledge earns its place only when it changes an inspection, experiment, budget, or design decision.

Text reaches the model as tokens

A language model does not receive a JavaScript string or paragraph in the form the user sees. A tokenizer maps text into a sequence of token identifiers from a fixed vocabulary. The model operates on those identifiers and their learned representations.

Many tokenizers use subword units. A frequent word may map to one token; a rare domain string may split into several. Punctuation, whitespace, Unicode normalization, capitalization, scripts, and special tokens can affect the sequence. The precise behavior belongs to the actual tokenizer paired with the model.

Consider three synthetic Mosaic messages:

1. English: Washer W-17 stops after rinse. Bulletin SB-4 mentions a latch check.
2. Gujarati: વોશિંગ મશીન રિન્સ પછી બંધ થાય છે. SB-4 જુઓ.
3. Code-switched: Machine rinse પછી stop થાય છે; latch error E17 દેખાય છે.

Counting words gives one view. Counting Unicode characters gives another. Neither reveals the model’s token sequence. A tokenizer may preserve SB-4 as a compact pattern or split the letters, hyphen, and digit. It may represent Gujarati text with shorter or longer sequences depending on vocabulary and training. The code-switched case may cross boundaries that one tokenizer handles compactly and another fragments.

The deterministic companion includes two deliberately simple pedagogical tokenizers. One groups runs of letters and numbers. The other splits longer runs into smaller pieces. They are not replicas of any managed provider or open-weight tokenizer. Their only valid lesson is that different segmentation rules produce different sequences and lengths.

This matters in four ways.

Capacity

Context limits are measured in model-specific units, usually tokens, not user-visible words. A case that looks short may consume more budget after tokenization and templating. The available input budget is also smaller than the nominal window because the system needs room for instructions, source markers, history, and generated output.

Cost and latency

Some access paths charge or schedule work partly by input and output tokens. More tokens can mean more compute, memory, latency, or cost, but the exact relationship is path-specific and must be measured. Do not infer a durable price or latency law from one provider.

Representation

Tokenization changes which units enter the model. Fragmentation can alter sequence length and the learned representations available to process a term. It is a plausible factor in domain and language behavior, but not a verdict. A message using more tokens is not automatically handled worse, and a compact encoding is not automatically better.

Compatibility

An open-weight checkpoint expects the tokenizer and special-token conventions used for its training. Pairing the wrong tokenizer or template with weights can produce severe behavior changes without a clean runtime error. Managed paths may hide or abstract this surface; the limitation should be recorded rather than guessed.

Subword tokenization changes sequence length and representation, with language- and domain-specific effects. Foundational subword research demonstrates techniques and motivations, but effects for Mosaic must be measured using the actual tokenizer, model, and template. Token count is a diagnostic and budget input, not a quality score. [CLM-008]

The template is part of the input

Chat-oriented models usually expect a serialization of roles and messages. The application may hold objects such as:

system: Proposal only. Cite supplied evidence.
user: Washer W-17 stops after rinse.
assistant:

The model receives tokens produced from a rendered representation, which may contain special control tokens, separators, end markers, or role headers. The correct representation is model-specific.

A managed API may perform some templating behind its interface. An open-weight library may expose a chat-template function tied to the tokenizer. In both cases, the engineer should record what is known.

A template can change behavior through:

• role markers and instruction placement;
• duplicated or missing special tokens;
• separator format;
• ordering of conversation history and evidence;
• inclusion of assistant-generation markers;
• padding and end-of-sequence conventions;
• additional token budget.

If training examples use one template and serving uses another, the model receives a different pattern from the one used during adaptation. If an application wraps an already formatted prompt again, duplicate control tokens can appear. If a provider changes hidden formatting, behavior may change even when application text does not.

“Same prompt” is therefore too weak for a reproducibility claim. Record the semantic message bundle and the exact path-specific serialization when observable.

From token identifiers to contextual representations

Token identifiers are looked up as vectors. Position information is incorporated so that order can affect computation. Layers repeatedly transform the sequence. In the original Transformer formulation, multi-head attention allows positions to compute weighted combinations of representations from other positions, followed by additional transformations.

For autoregressive generation, the model’s computation at a step is restricted to prior context rather than future generated tokens. The resulting state is used to produce scores over the vocabulary for the next token. A decoding procedure selects a token, appends it to the context, and the process repeats.

At decision depth, three consequences matter.

Context is represented, not stored as a database row

The system does not retrieve a sentence from the context by using a guaranteed key-value lookup unless separate deterministic or retrieval software provides that function. The model computes contextual representations. Exact copying and evidence use are behaviors to test, not properties to assume.

Order and position can matter

Moving an instruction or fact changes positions and interactions. Repeating text adds competing material. A long signature or quoted thread can consume budget and alter which evidence is easy to use. Later chapters will test long-context position and retrieval; here we identify the mechanism-facing reason to care.

Layers do not create authority

Attention-based computation can combine information from prior context. It does not determine whether a source is authorized, whether a warranty rule is controlling, or whether a proposed effect is permitted. Those remain system and authority decisions.

The original Transformer paper is a foundational mechanism source. LLME-CASE-001 retains its machine-translation task, hardware, and historical limits rather than turning those results into Mosaic evidence. The paper does not establish that a current chat model is truthful, safe, or fit for this system. Transformer generation conditions each next token on represented prior context through attention-based layers. Modern architectures add variations and other mechanisms. [CLM-007]

Long description

Text cards enter a bead-like gate labeled tokens. Positioned token beads enter a layered field labeled attention. The field produces a set of next-token scores, and one route reaches a token labeled next. A note states that decoding chooses the route. No human-like head or brain appears.

Attention is not an explanation label

The word attention invites anthropomorphism. In ordinary language, attention suggests awareness, intention, focus, or importance. In a Transformer, attention names a parameterized computation over representations.

Avoid these statements:

• “The model paid attention to the safety bulletin.”
• “The model ignored the customer.”
• “The attention score proves which source caused the answer.”
• “The model understood the warranty condition.”

Use observable or mechanistic language instead:

• “The generated proposal cited the bulletin and reproduced its stop condition.”
• “The output omitted the customer-reported symptom in this run.”
• “Under this configuration, moving the bulletin changed the response distribution.”
• “The model produced a token sequence consistent with the condition, but source support and domain correctness still require evaluation.”

Even when an implementation exposes attention weights, using them as a complete causal explanation requires a separate interpretability claim and method. That is outside this chapter. AI Research and interpretability specialists own deeper novel claims. The LLM Engineer uses mechanism literacy to design tests and avoids laundering an internal signal into an explanation.

Next-token scores are not truth probabilities

At each generation step, the model produces scores that can be transformed into a distribution over the next token. The distribution is conditional on the represented context and learned parameters. It answers a computational question about continuation under the model. It does not directly answer:

• Is this sentence factually correct?
• Is the cited bulletin authoritative?
• Is this recommendation safe?
• Is warranty approval permitted?
• Will the user achieve a beneficial outcome?

A locally high-probability token can participate in an unsupported statement. A low-probability path can contain a correct rare part number. Factuality and authority need external evidence and system controls.

This also explains why a generated confidence phrase is not calibrated uncertainty. If the model writes “I am 90 percent certain,” the number is generated text unless a separately designed method gives it meaning. Mosaic’s uncertainty state must be tied to observable evidence conditions and evaluation, not stylistic confidence.

Decoding turns scores into a response

Decoding determines how the system selects tokens from model scores. Several families are useful to distinguish.

Greedy selection

Greedy decoding selects the highest-scoring available token at each step. Under a fixed implementation and configuration it may reduce sampling variation, but it does not guarantee the best complete sequence, factual correctness, or bitwise repeatability across every system.

Sampling

Sampling draws from a transformed distribution. Parameters such as temperature and top-p change which tokens remain likely to be selected. Sampling can produce varied responses from the same input and model. The application must decide whether variation is acceptable and how many trials an evaluation needs.

Beam-style search

Beam methods track several partial sequences and compare aggregate scores. They are useful in some tasks and less common in others. Their existence does not create a universal quality hierarchy.

Constrained generation

Some runtimes restrict token choices so that output matches a grammar or schema. This can strengthen structural validity. It cannot establish that a source supports a field or that an effect is authorized.

Decoding is a tradeoff surface, not a personality dial. Raising temperature does not make a model creative in a human sense. Lowering it does not make the model truthful. Each configuration changes the distribution of observable responses and belongs in behavior identity.

Long description

A branching terrain represents possible next tokens over several steps. One solid route labeled greedy takes the locally highest branch. Several dotted routes labeled sampled show possible draws. A route labeled constrained passes through a mechanical gate that blocks invalid branches. All routes begin from the same context marker.

Behavior identity is larger than a checkpoint

For a Mosaic run, record at least:

• model/provider identifier or checkpoint revision;
• tokenizer and revision when observable;
• chat template and special-token behavior when observable;
• semantic system, user, and context messages;
• decoding method and parameters;
• maximum input/output limits;
• structured-output or grammar constraints;
• runtime/library version;
• relevant provider feature version;
• date and environment;
• raw response and validation result.

The correct depth differs by access path.

Managed path

The team may know the endpoint, model identifier, request parameters, documented limits, and returned metadata. The exact weights, tokenizer revision, hidden template, or serving runtime may be unavailable. Record the unavailable surface. Do not substitute an open-source tokenizer merely because its counts look plausible.

A stable identifier may still sit behind provider-managed updates. Later release chapters will require regression replay and migration controls.

Open-weight path

The team can usually pin a weight revision, tokenizer files, template, generation configuration, runtime, and hardware. That improves reproducibility and diagnosis while increasing responsibility for artifact compatibility, security, performance, and lifecycle.

Open weights do not create full epistemic transparency. Training corpora, post-training decisions, numerical behavior, and internal causal explanations may remain incomplete.

Decoding and chat-template configuration are part of behavior identity and must be versioned. Current library documentation shows available strategies and template mechanisms, but defaults and APIs change, and the correct template is model-specific. Recheck them for the actual version. [CLM-009]

The Mosaic token-and-template investigation

Use the deterministic companion to create a mechanism-consequence sheet before model selection.

The companion takes four synthetic messages and one template. It reports counts under two pedagogical tokenizers, the rendered template, a simple input/output budget, and a trace hash. It makes no model call.

Run:

node content/publications/llm-behavior-engineering/companion/run.mjs

Inspect three questions.

1. Does representation vary?

Compare English, Gujarati, and code-switched fixtures under both teaching tokenizers. The counts and pieces differ. The only justified conclusion is that the tokenizer matters. To make a claim about a candidate model, repeat the inspection with that model’s actual tokenizer or record that the managed path does not expose it.

2. What did the template add?

Compare tokens for raw message text and rendered text. The system instruction, role markers, separators, and generation marker consume budget. The template also carries control semantics expected by the model.

3. Can reserved output expose overflow risk?

The fixture reserves part of a synthetic 64-unit budget for output. The long message overflows under at least one teaching tokenizer after templating. This is not a model context-window result. It demonstrates the accounting method: subtract control/template and output reserve before deciding what evidence fits.

The trace hash identifies the input/template/tokenizer fixture result. It does not prove semantic equivalence or quality.

Failure injection: the instruction that disappears

Construct a long Mosaic thread with repeated signatures, quoted history, and a current safety bulletin near the end. Render it with the exact candidate template.

Now test two systems.

In System A, the application truncates from the beginning after formatting. The early system instruction that says “proposal only” is lost. In System B, the application preserves instructions but drops the current safety bulletin. Both inputs may fit a nominal window before templating. Both failures arise from system policy, not from a model deciding to disobey or forget.

The correct response is not to write “be careful” twice. It is to:

1. measure the rendered sequence;
2. reserve output capacity;
3. define non-droppable control and evidence classes;
4. make omissions visible in the trace;
5. specify overflow behavior such as compression, clarification, abstention, or escalation;
6. test the policy with representative long cases.

Chapter 8 will design the full context budget. Chapter 3 records the plausible mechanism and the required experiment.

Failure injection: the decoding change called a model improvement

Suppose two Mosaic runs use the same model identifier and message text. The second produces shorter, more consistent proposals. A report says, “The model improved.”

The run records reveal that temperature changed, a schema constraint was added, and the chat template library was upgraded.

The observation may be real. The attribution is not. The configured systems differ in at least three ways. Restore a controlled comparison or report the result as a system-configuration change. Chapter 5 will establish the reproducible baseline; Chapter 15 will formalize isolated experiments.

An engineering vocabulary without mental states

Use these substitutions throughout the book:

Avoid	Prefer
The model understands the case	The response satisfies specified case criteria under configuration C.
The model remembers the bulletin	The generated output reproduces or uses information present in the supplied context.
The model paid attention	The output changed when evidence position or content changed; the mechanism hypothesis requires testing.
The model knows Gujarati	The configured system meets defined Gujarati task criteria on a named case set.
The model is confident	The output uses a confidence phrase, or a separately defined uncertainty measure has value X.
The model decided to escalate	The configured generation and deterministic application produced the escalation state.

This language is not pedantry. It makes claims testable and keeps authority outside generated prose.

Practice: predict, trace, test

Choose the three short Mosaic fixtures.

1. Predict which message will create the longest sequence under each pedagogical tokenizer and write why.
2. Run the companion and compare the prediction with the trace.
3. Identify which part of the result is an observation and which part is an inference.
4. Add one domain term and one punctuation change. Record the new trace hash and counts.
5. Change one generation-configuration field and confirm that behavior identity changes.
6. Design a real candidate test without assuming the teaching tokenizer transfers.

Then analyze the long-thread failure.

• Which inputs are non-droppable?
• Which evidence may be summarized?
• How much output headroom is reserved?
• What should happen when the budget cannot hold required evidence?
• Which observations would distinguish template overhead, truncation policy, evidence position, and decoding as causes?

Pass when the trace is reproducible, every mechanism statement is bounded to what the inspection can show, and at least two alternative explanations remain for an observed output difference.

The MD-02 mechanism handoff

Mosaic Desk now enters MD-02 with a mechanism-consequence sheet.

It records:

• tokens rather than words as the model-facing sequence unit;
• actual tokenizer inspection as a requirement where observable;
• exact chat serialization as part of behavior identity;
• context and reserved output as finite budget consumers;
• attention-based contextual computation as a mechanism, not an explanation or authority;
• next-token scores as continuation scores, not truth probabilities;
• decoding as a versioned behavior configuration;
• managed-path unknowns and open-weight compatibility responsibilities;
• truncation and configuration-change failure injections for candidate testing.

The sheet does not rank models. Chapter 4 will combine it with the MD-01 behavior contract, representative seed cases, privacy and control constraints, and operational assumptions to select an initial model and access posture. A candidate earns consideration by measured task evidence and responsibility fit, not by architecture prestige or benchmark rank alone.