Chapter 4 – The Stochastic Generator (Why You Need Physics)

Update the Map’s ## Public Interfaces block to match the exported signatures in the Terrain.

Run 1:

• normalize_country(country)
• calculate_tax(amount, country, rate)

Run 2:

• normalize_country(country: str) — Normalize an input country string.
• calculate_tax(amount: float, country: str, rate: float) — Compute tax for an amount.

Both are reasonable enough to pass a weak Validator set. If the only checks are “valid Markdown” and “the Map mentions the right function names,” neither check catches the difference. But only Run 1 matches the canonical signature surface declared for this example. Run 2 invents type annotations and adds prose.

That gap is the chapter’s subject. This is drift on a bounded surface: the same task, the same apparent intent, different outputs. It is why the governed Map surface and observed Terrain must remain distinct, with authority declared for the specific property.

A Map is the structured representation being governed. It may express adopted intent or record selected observed structure. Terrain is the system state the workflow observes or proposes to change.

Part I established the mechanism before the theory. Part II explains why it needs external checks and enforced limits, which the book calls Physics. Lower-level evidence may inform higher-level Maps, while adopted Maps constrain the workflows below. Variance is the starting condition those workflows must manage.

Large Language Models (LLMs) are Stochastic Generators: probability models that produce plausible outputs, not guaranteed ones. Reliable automation puts deterministic checks around generation. The full Software Development as Code (SDaC) runtime is the SDaC Engine; the model is one component inside it.

LLMs Are Probability Generators

At its core, an autoregressive LLM assigns probabilities to possible next tokens. The decoder then selects or samples a token according to its configuration. Small differences early in that sequence can produce materially different candidates.

Three implications matter in SDaC:

• No guarantee of identical output: With sampling enabled, the same task request can produce different candidates across runs. Even when a provider supports greedy decoding or a temperature of 0, do not assume exact replay unless the full inference path provides that guarantee.

• Contextual sensitivity: Small changes in input or context can shift the distribution and change the output.

• Small variations can cause distant effects: A minor output change can alter another interface, file, or behavior without producing a simple local failure path.

This is why SDaC treats generation as one component in a system, not as the plan itself: you measure variance, constrain it, and gate it.

The Specifiable / Problem-solving / Evolutionary (S/P/E) Mismatch

Lehman’s frame separates three different kinds of software work.¹ In plain language: some systems are exact, some are heuristic, and some live in a changing world.

1. S-Type (Specifiable): The problem is formally defined. Correctness is absolute. A compiler or schema validator is S-Type.
2. P-Type (Problem-solving): The solution is judged by acceptability rather than a complete formal specification. Bounded LLM generation is P-Type work in this frame.
3. E-Type (Evolutionary): The system is embedded in reality. Because the world changes, the software must keep changing to stay useful. Your production codebase is E-Type.

Lehman’s First Law says an E-Type system must be continually adapted, or it becomes progressively less satisfactory. Raw one-shot generation does not solve that evolutionary problem: the system and its environment continue to change while the generator sees only a bounded, partial representation.

When you use a raw AI assistant, you are asking a Stochastic Generator to perform P-Type work directly on an E-Type system: a heuristic component touching a changing real-world codebase.

An unconstrained Stochastic Generator produces variants, some of which violate the realities of the E-Type environment. The variance is stochastic drift; a violated constraint is a validation failure.

In short: AI performs P-Type work through a Stochastic Generator, the real-world system is E-Type, and SDaC places deterministic boundaries between them.

The SDaC Synthesis: P-Type Work Behind Deterministic Boundaries

Formally grounded Validators can be implemented as S-Type components: parsers, schema checks, type boundaries, and other exact checks. Rule-based and behavioral grounding add authored constraints and observed cases where formal completeness is impossible.

This is the theoretical justification for the Deterministic Sandwich from Chapter 2. Deterministic Prep and Validation bound the Stochastic Generator’s P-Type work without pretending every rule is formally complete.

Every Validator supplies findings at an enforceable boundary. Its grounding may be formal, rule-based, or behavioral, but its result is still explicit evidence for routing, including a Judge when one is needed.

Generative AI Changes the Rate, Not the Evolutionary Problem

The S/P/E mismatch describes the risk around one generated candidate. Lehman’s broader laws describe pressures that emerge as an E-Type system changes repeatedly.² They apply to the evolving system and its development process, not to the model in isolation. The applications below are the author’s synthesis.

The laws matter here in three groups: continuing change and growth create pressure to act; increasing complexity and declining quality create costs; organizational limits and feedback constrain how quickly useful change can be absorbed.

The First Law, Continuing Change, and the Sixth, Continuing Growth, establish that an E-Type system must keep adapting and developing useful capability. Generative AI makes proposals for both cheaper. It does not establish that a proposal reflects current intent, fits the system, preserves existing obligations, or deserves admission.

The Second Law, Increasing Complexity, and the Seventh, Declining Quality, describe two costs of repeated change. New abstractions, dependencies, and exceptions can accumulate faster than they are integrated, while the operating environment can move away from assumptions that were once valid. A generator evaluated against stale checks can optimize an obsolete target efficiently. Deliberate simplification and refreshed evidence therefore belong inside evolutionary work.

The Fourth Law, Conservation of Organisational Stability, and the Fifth, Conservation of Familiarity, concern limits in the activity and shared understanding around evolution. AI may alter their historical rates, but candidate output is not completed work. Intent, validation, review, integration, and learning still consume scarce capacity. A larger context window also does not explain why an interface exists or which external promise depends on it. Work and evidence must remain small enough to reconstruct.

The Third Law, Self-Regulation, and the Eighth, Feedback System, frame evolution as a constrained, multi-level feedback process. Faster proposals can reappear as review queues, failed checks, reversions, or delay until throughput stabilizes at an expensive or unsafe point. Explicit budgets and stopping rules make those pressures visible. The Ledger must also keep observation, proposal, validation, and admission distinct so a workflow cannot treat its own output as proof.

These laws are empirical tendencies, not formal invariants, and the evidence behind them was uneven, particularly for the Fourth and Seventh Laws. Generative AI may change their rates. It does not abolish the underlying need to keep an E-Type system useful under changing conditions.

Chapter 14 returns to the strategic consequence: proposal speed matters only as part of the full time to a governed response. It names and measures that interval as adaptation latency, then develops the author’s competitive hypothesis for environments where other organizations also accelerate search and implementation.

Operating a Stochastic Generator

Pin whatever the provider exposes: model identity, decoding controls, request, context, tool versions, and any provider-supplied identifier that helps determine whether two runs used the same inference path. Then measure the exact workflow rather than copying a universal temperature or seed. A tight output contract matters more than a fashionable parameter value.

Better models and prompts can improve candidate quality. Use the least expensive combination that reliably reaches the required checks within the declared attempt, time, and cost budgets. Mechanical edits under strict gates may need little capability; ambiguous cross-surface work may need a stronger model or a human decision. Compare alternatives only inside the same bounded workflow and checks.

Internal Reasoning Does Not Replace the Loop

Models may deliberate before producing an answer, and some APIs expose summaries of that reasoning.³ Deliberation can improve a candidate, but it is not independent evidence. In a tool-enabled runtime the model may request a compiler or test run; the evidence comes from the recorded tool result, not from the model’s prediction of it.

Reasoning capability may improve the change step. It does not turn the model into the external check or make “thinking hard” equivalent to a test passing.

The Drift Experiment: Measure Structural Variance

Repeat one bounded task under fixed inputs and controls. Distinguish textual variation from structural variation, failures, and the time or attempts needed for a passing proposal. Two patches may differ in whitespace yet make the same structural change; two polished patches may touch different interfaces or files.

This is a local operating observation, not a general model benchmark. If unwanted structural variation or failure remains high, narrow the context and edit region, strengthen the checks, or use a more capable generator. The point is to make variance visible enough to govern.

Why Ad-hoc Instructions Stop Scaling

More specific instructions can reduce variation, but they cannot eliminate sampling or enforce their own interpretation. Extract the skeleton and edit region deterministically, generate only inside that boundary, and reject unwanted structural variance with Validators. Instructions shape a candidate; Physics decides whether it may advance.