# The Language Between Languages
# Book: Language
# Chapter URL: https://programmer.ie/books/language/11-chapter/
# Prose fingerprint (sha256, normalized): 84db7b8616cfcff8bd97787058b8b4b41819d98efc198123de738cfface7bd94
# Snapshot generated at build time by Hugo. This is the complete rendered prose
# of the chapter; it is not a transcript of the source file.

A product owner asks for a job queue with two properties: “A job must never be executed twice” and “A job that fails for a transient reason should be retried up to three times.” They sound clear until a worker times out after charging a card. The caller cannot tell whether the charge happened, so it retries. Does “executed” mean that the worker ran, that the queue recorded a completion, or that money actually moved? Under the first reading, another attempt breaches the prohibition. Under the second, the queue may record one completion even after two charges. Under the third, the retry is permissible only if it cannot commit a second charge. The ambiguity is not a linguistic curiosity: each reading permits different observable behaviour. This is a constructed example, not an incident report.
Someone building the queue chooses the second reading: at most one recorded completion for each job. They implement a checker, run every test, and report that the invariant holds. But consider a trace: the first attempt charges the card, loses its acknowledgement, and is marked failed; the next attempt charges the card again and reports success. The system records one completed job and two external effects. The checker is not necessarily defective. It checked the property it was given. The missing step was asking the owner whether “never executed twice” meant never charge twice. A specification can be internally consistent and still represent the wrong obligation. Real systems often use idempotency keys and durable effect records to address that boundary; declaring a unique completion record does not implement those safeguards.
This chapter is about that mismatch between what was requested, what was formalised, what was checked, and what actually happened. Chapter 10 required preservation obligations to be declared before a transformation. Here we follow one obligation across forms—from a person’s request into structured requirements, machine-checkable properties, and an observable operation—and ask at each boundary who made an interpretive choice and what evidence could expose a wrong one.
Between ordinary human language and executable machine state, what kinds of representation are available, and what does each make easier or harder?
A ladder of ways to say the same thing Take the queue requirement and make it successively more explicit. The sketch below deliberately follows the builder’s recorded-completion interpretation, not the owner’s subsequently revealed concern about duplicate charges. That is the trap: a series of mutually consistent representations can all inherit the same initial mistake. “Up to three retries” is also ambiguous unless we say whether the initial attempt is counted; below, retries exclude that first attempt.
natural prose "A job should never run twice, but transient failures should be retried." controlled prose "Each job has at most one completed execution. A failed attempt marked transient may be retried up to 3 times." structured requirements R1 recorded completions per job <= 1 R2 additional retries per job, cause = transient <= 3 schemas and constraints fields: job_id, attempt, status, cause constraint: count(status = completed, by job_id) <= 1 missing: external-effect identity and deduplication rule executable contracts a test or runtime assertion that fails when the constraint breaks state-transition representations states and allowed moves: pending → running → completed, or running → failed(transient) → pending (at most 3 times) formal specification or proof a statement of the invariant in a logic, with assumptions stated, and a demonstration that the model satisfies it machine-native operational state the queue's actual configuration and runtime records Notice what happens as you move between forms. The controlled sentence fixes one definition; the constraint makes that definition countable; the transition model names possible movements through state. Those changes can expose ambiguity and permit new checks. They cannot recover the interpretation discarded at the first step. Nor is the movement strictly one-way: a formal model can express behaviours prose did not mention, while an operational log can reveal a failure no abstract schema included. Readability is not guaranteed to decline at every step, either: a well-chosen diagram or trace can make a constraint easier for its owner to inspect than an obscure paragraph. The question is which distinctions become explicit, lost, or newly testable in this move.
Call it a representation ladder for orientation, not a guarantee of increasing precision, expressive power, or fidelity. Some rungs are alternative views rather than refinements of one another: a state-transition model describes allowed behaviour, a test observes selected executions, a proof establishes a property under premises, and a runtime trace records what occurred. None subsumes the others automatically. A useful traversal may move up, down, or sideways, and should preserve the link back to the owner’s words.
Proposed ladder of representational forms. More checkable may mean less expressive; more executable may mean more assumptions made without anyone choosing them. Open full-size diagram. Six things to ask of any rung Six questions help compare representations. They are dimensions to investigate, not scores assigned by the notation alone. The final three, in particular, require a stated task, a human or operational oracle, and an account of what was actually observed.
Question What it asks Expressiveness Which distinctions, exceptions, and alternatives can this form state? Ambiguity Which interpretations remain open, and which were settled by whom? Checkability Which explicit properties can a checker test or prove, over which assumptions and states? Intent preservation Does the chosen reading retain what the requester would accept in the relevant cases? Executability Can a machine use the form to constrain or drive an operation, and with what authority? Reconstructability Can the affected person recover and challenge the operative meaning from this form? Natural prose often makes goals, caveats and negotiations accessible; it can also conceal contradictions. A formal model may make particular claims decidable or provable while omitting the boundary the owner cares about. A readable diagram may outperform both for a particular review question. The six dimensions should therefore be evaluated on specified cases rather than assigned universal high and low rankings to whole notations.
Intent preservation is different from syntax validity. It concerns the relationship between a representation and the requester’s actual purpose under the conditions of use. Asking the requester is often necessary, but a nod to a paraphrase is not sufficient evidence in a consequential case. Present concrete counterexamples—such as “a card was charged, but the completion was not recorded”—and ask whether the proposed requirement permits them. Keep the accepted choice, the source span, the examples considered, and the identity of the authority who accepted it. Even that establishes a bounded agreement, not access to someone’s complete inner intent.
More formal is not better The temptation is to read the ladder as progress and conclude that the further down you go, the better. The trade-offs say otherwise.
more checkable may mean less expressive more executable may mean more assumptions made explicit, some of which nobody chose more precise may mean some human intent has been discarded Precision can expose a question prose left open. It can also conceal who answered it. In the queue, someone equated “executed” with “recorded as completed,” and every later constraint inherited that choice. The owner meant “one charge per intended payment,” an obligation about externally observed effects, not job status. The safer move is to preserve the alternative readings until the decision is made, record the chosen interpretation and its scope, and include a counterexample that would distinguish it from its rivals. Precision is only a gain when the interpretive commitment remains inspectable.
So the central claim of this chapter can be stated plainly:
A representation can become easier for a machine to verify while becoming worse at preserving what a human meant.
This is not an argument against formal representations. It is an argument against treating verification as if it were fidelity. Three things that are easy to run together need to stay apart:
intent preservation ≠ checkability ≠ implementation conformance An implementation can conform to a specification while the specification omits the customer’s actual concern. More precisely, the available assurances differ: a passing test establishes behaviour only on the executions tested; finite-state model checking examines behaviours within its encoded model and bounds; a proof establishes a proposition from stated axioms and assumptions; independent observations establish something about the deployed system. None alone proves that the original requirement was elicited correctly, that the model includes every relevant external effect, or that the code-to-model mapping is sound. A perfectly valid proof of “at most one recorded completion” is compatible with a double charge if charging was excluded from the model. Formal methods make the claim checkable; they do not choose the claim on the owner’s behalf.
What a mediator could do here If the ladder is a space of trade-offs, where does intelligence in the channel fit? Not in replacing ordinary language with formal notation. The more interesting possibility is a mediator that helps a person move between rungs without hiding the decisions along the way.
Picture a mediator helping rather than deciding. It highlights the word “executed” in the owner’s original request and proposes three readings, each attached to a small trace that distinguishes it from the others. It asks what should happen when a payment succeeds but its acknowledgement is lost. The owner may select a reading, revise the request, or leave the issue unresolved. Only the settled obligations are compiled into checks, and unsettled ones remain visibly blocked; no generated default is silently promoted. The mediator then renders the chosen properties back into plain language, with a trace to the original words, the examples used to settle them, and the checks that can actually run. A human confirmation is tied to that exact version and becomes stale when its meaning changes.
This is the preservation contract from Chapter 10 applied to specification work. Across each step, mark what survived, what was narrowed by agreement, what was added as a new assumption, and what remains unresolved. A renamed field, a missing exception, or a newly introduced definition can be legitimate if its origin and authorisation are visible. A check should distinguish “the new form is internally valid” from “the owner accepted this interpretation.” A reversible path matters as much as forward compilation: an affected person should be able to challenge a property and inspect the wording and evidence that produced it.
Whether this mediation improves anything is an experimental question. It may reduce silent assumption-making while increasing review time, or simply move the labour of formalisation into a stream of generated proposals. A polished restatement may even increase false confidence. The appropriate comparison is not against a caricature of unstructured prose: it is against competent human clarification and ordinary requirements review, with both incorrect commitments and review effort counted. The proposed evaluation later in this chapter leaves those outcomes open.
Machines as an audience This belongs in a book about communication because software has long been an audience for instructions: command languages, configuration files, contracts and programs already translate human purposes into machine operations. AI does not invent that boundary. It makes more of the interpretation at the boundary variable, generated and conversational—and therefore creates new ways for a wrong reading to appear authoritative. The design problem is not to make every conversation executable, but to decide which parts are ready to become operational commitments.
People often repair ambiguity conversationally, but may also agree without sharing the same interpretation. Machines cannot rely on that repair when an action has consequences: the permitted effect, its triggering condition, and the actor authorised to cause it need an explicit contract. A mediated representation can help carry a human request toward such a contract and carry a machine’s observed state back in understandable form. The two directions require different evidence: a request needs interpretation and approval; a report of execution needs independent observation. Neither becomes reliable simply by being fluent.
Operational state is not inherently a final, more advanced rung of language. It is a different kind of object: the records and effects of what a system actually did. A log entry that says “completed” can be wrong or incomplete about an external charge. Making that state legible to a person requires a rendering, but the rendering must link to observations and be clear about gaps. This matters later when Language considers delegation: the person must be able to contest not just a generated explanation of an action, but the authority and evidence for the action itself.
Words at the boundary Return to “executed.” A mediator could expose it as a bounded, still unresolved interpretation rather than allow the first generated definition to settle it. A choice among options does not by itself decide whether a duplicate charge is permissible. The meanings have to be attached to the source request and tested with distinguishing examples:
"executed" means: attempt completed job external effect The value of a typed choice is that the available readings, their definitions and any refusal to decide can be made explicit in the program’s interface. That is a useful constraint on a component’s output, not a guarantee that the component chose correctly or that the programmer supplied every relevant option. Adding an UNRESOLVED outcome and requiring authorised confirmation prevents an uncertain model choice from silently becoming a requirement. When the choices themselves are defective, the correct response is to revise the option set, not force the nearest label.
Classification, entailment, label-probability readouts, constrained decoding and model cascades all predate today’s typed-decision products. Jev is a hosted commercial example and Laya offers open-weight implementations, but the software-facing idea is wider than either product: a caller specifies a bounded decision and receives structured output without asking for a free-form justification. The early evidence audit by Tang and Zheng (2026) did not establish a general accuracy advantage for the new readout over comparable existing techniques; its reported efficiency benefits and limitations belong to the systems evaluated in that early literature. EvaluatorDPT offers a separate example of treating deferral as a learned output. None of these interfaces supplies authority to settle the owner’s requirement, and their probabilities are not automatically calibrated for this use.
One especially relevant reported failure concerns the names of the options. Sun and Xu (2026, v1) exchanged which option name was bound to each rubric while holding the question, state and rubric wording fixed. In one reported 1,200-decision setting, replacing neutral 0/1 names with semantically loaded no/yes names produced 70.4 additional answer flips per hundred relative to the comparison reported by the authors (95% interval 67.6–73.1); AUC shifted from approximately 0.94 to 0.23 while type-error rate remained 0%. Those are results from the study’s specific models, predicates and evaluation procedure, not a prediction for this queue or every typed model. Their value here is that a schema-valid response can follow the label’s ordinary associations instead of the definition a programmer intended.
In the queue example, attempt, completed job and external effect are not neutral strings. Their everyday associations might influence a model even when each is accompanied by a careful definition. The lesson is to preserve the binding among option identifier, rubric, evidence span, selected value and version, and to test perturbations of names and order before trusting the decision. A successful schema check can show that the reply is one of the allowed labels while saying nothing about the interpretation on which a consequential action would depend.
type conformance ≠ semantic correctness A typed decision is not the ladder’s “most explicit rung.” It is one narrow way of resolving a named uncertainty at a boundary. A formal invariant, a state machine and an external-effect receipt express different things that cannot be reduced to one enum. The useful distinction is that a typed answer can be syntactically constrained, while its semantic binding and decision authority still require separate checks.
Context Language Models (Shao and colleagues, 2026) provide a relevant but separate line of work: treating a model’s working context as an editable file and studying what the model learns to retain and update. That is evidence about context management within the paper’s experimental arrangements, not evidence that an editable file accurately represents a person’s intent. The semantic record in Chapter 7 has another role: a derived interpretation of a particular source, with its own provenance and preservation duties. A plugin may also maintain a text file, but sharing the medium of storage does not make these mechanisms equivalent. In particular, a model’s ability to rewrite working context must not silently grant it authority to rewrite an accepted requirement.
maintained state: what currently applies typed decision: a bounded question asked of that state renderer: an optional human-facing presentation A typed decision can consult maintained state and propose a bounded update, but state persistence is not semantic preservation. The accepted interpretation, the model’s latest proposal, the external evidence and the operational state must remain distinguishable. Generated explanations are useful presentation, not causal logs: the record of why an action was permitted is the actual decision, its bound inputs, its authorisation and the checks performed. This brings together the Context book’s distinction between available and admitted information, Memory’s distinction between a stored past and a useful one, and this book’s distinction between intent and reconstruction; it does not transfer measured results from those books to Language.
Hao and colleagues’ continuous latent reasoning work already explored feeding hidden states back into generation without selecting an ordinary token at every step. Large Concept Models investigate a different approach, operating over sentence representations; the two mechanisms should not be equated. HybridAgent (Zou and colleagues, 2026) extends the latent-feedback setting through interleaved text and latent computation, tool interaction, and dedicated supervised and reinforcement training. Its learned HybridLink maps hidden states into subsequent inputs, while what the authors call continuous working memory retains text, latent steps and tool observations across turns. The paper reports performance on its reasoning benchmarks; it does not test whether the queue owner’s intended rule reaches another participant intact.
Three objects remain distinct: the internal computational representation, the external communication representation, and the transformation connecting them. Continuing a model’s working memory is different from maintaining our source-linked semantic record or a person’s durable memory. An interesting model-level mechanism is not a preservation guarantee implementable by a plugin through an ordinary hosted-model interface. Nothing in these papers establishes that a latent state preserves a particular owner’s intended business rule. The relevant engineering obligation remains external and testable: what interpretation did the system use, what evidence supports it, and who permitted its consequences?
A proposed cross-rung test The queue is a useful demonstration, but it is too small to establish that an AI mediator improves requirements work. A fair experiment would freeze several constructed, independently adjudicated task families: retry/side-effect ambiguity, scope-limited policy, temporal constraints and deliberately underspecified authority. For each task, preserve the original request, a set of distinguishing traces, and the intended acceptance rules in a sealed reference packet. The reader-facing systems must not see that packet.
Compare four conditions with the same task material: ordinary requirements review, with a human analyst clarifying the request; direct formalisation, in which a model produces a structured contract for human review; mediated formalisation, in which the model must expose readings, counterexamples, explicit approvals and source bindings; and a strong human-authored structured baseline where feasible. Allow UNRESOLVED in every condition; do not reward a system for guessing when the requirement does not determine an answer. Freeze the model, tools, task order and review budget, and vary only the mediation being tested.
Score separate outcomes: (1) whether the accepted requirement matches the sealed task oracle on held-out traces; (2) whether its checks find duplicate effects and other planted violations; (3) the rate of unjustified or stale confirmations; (4) reviewer time and correction burden; and (5) confidence before and after testing, to detect false assurance. Inspect failures separately at interpretation, formalisation, checking and execution-observation boundaries. Repeat model-backed conditions rather than treating one fluent answer as a measurement. A mediator that creates better-looking contracts while raising false acceptance or review cost has not earned promotion. This test is proposed, not run; the scripted example below does not supply its results.
Running it The reference implementation (ernanhughes/project-language) exposes npm run example:ch11. It uses a constructed job-queue trace and the three readings of “executed”, with a scripted stand-in on a Pi host; it makes no real model call. This is a demonstration of boundary and bookkeeping behaviour, not a measurement of semantic accuracy, user comprehension, or formal-proof correctness.
The implemented portion makes a particular interpretation inspectable and prevents a model proposal from silently becoming an approved requirement. A chosen option and its definition are bound to the source wording; a change to that wording invalidates the binding. A check dependent on an unresolved reading returns inconclusive. The model can propose a reading and request a check, but only the reader can settle it; a later proposal cannot displace a settled choice. Human confirmation is bound to the exact reading and becomes stale when it changes. Under “completed job”, the constructed trace passes despite the two charges; under “external effect”, it fails. This demonstrates how an explicit choice changes the checked property. It does not demonstrate that the choice was the owner’s true intent or that the live external system prevents duplicate effects.
The example additionally varies option names and their ordering while keeping definitions fixed. Its deliberately defective scripted selector changes answers, so the local probe detects a constructed name-sensitivity failure. This neither reproduces Sun and colleagues’ model study nor tests a real model. The program does not implement all the ladder’s forms, prove a real queue correct, compare against competent human review, or measure whether a user benefits. Those are open questions assigned to the proposed experiment rather than claimed as results.
Where this leaves us Between natural prose and operational state lie several useful kinds of representation: controlled wording, structured obligations, executable checks, transition models and formal specifications. They are not a universal hierarchy of truth. Making a requirement machine-checkable forces interpretations into the open, but a passing check may faithfully verify the wrong interpretation, and a valid proof may omit the effect the owner cares about. A typed choice is one tool for exposing a disputed reading, not a substitute for preserving its source, gaining approval and checking observable consequences. The mediator’s possible contribution is to keep those commitments inspectable and correctable across forms; whether it does so more effectively than ordinary review remains to be established.
The preceding chapters supplied the pieces: source-linked interpretations, rendering choices, external material kept distinct, and explicit preservation obligations. Chapter 11 now adds a rule for moving among human-readable and machine-checkable forms without confusing a well-typed answer with an accepted meaning. The next chapter, The Semantic Browser, composes those pieces. Its first task is not to generate the most impressive interface; it is to show which source, interpretation, obligations and checks produced each view—and when the responsible answer is to leave the source alone.
References Lamport, L. (2002). Specifying Systems: The TLA+ Language and Tools for Hardware and Software Engineers. Addison-Wesley. (Formal specifications and the limits of checking within a model.)
Featonby, M. (2021). “Making retries safe with idempotent APIs.” Amazon Builders’ Library. https://aws.amazon.com/builders-library/making-retries-safe-with-idempotent-APIs/ (An engineering account of retries, externally visible effects, and idempotency; not a Language experiment.)
Hao, S. et al. (2024; revised 2026). Training Large Language Models to Reason in a Continuous Latent Space. arXiv:2412.06769.
LCM Team et al. (2024). Large Concept Models: Language Modeling in a Sentence Representation Space. arXiv:2412.08821.
Zou, J., Qi, Y., Chen, S., Bianchi, F., Zhu, S., Lu, P., He, J. & Zou, J. (2026). Hybrid Reasoning Agents. arXiv:2610.18861v1. https://arxiv.org/abs/2610.18861v1. (Sections 3–4; a model-level case of latent computation with textual interaction, not evidence of communicative preservation.)
Shao, R. et al. (2026). Context Language Models. arXiv:2609.37725.
Chandrasekaran, S.P. (2026). Auditable Decision Models with Learned Abstention and Real-Time Steering (EvaluatorDPT). arXiv:2605.27768.
Tang, L. & Zheng, Y. (2026). Typed Decision Models: An Early Evidence Audit and Evaluation Checklist. arXiv:2609.32160.
Sun, Y. & Xu, J. (2026). Type-Safe Is Not Error-Free: A Constrained Decision Head Follows the Option Name, Not the Rubric Bound to It. arXiv:2609.26758v1. https://arxiv.org/abs/2609.26758v1. (Cited for one reported result in the setting the authors evaluated; the magnitude is not generalised.)
TypeSafe AI (2026). Jev product description. https://typesafe.ai/blog/introducing-system-one-models-and-jev (accessed 22 October 2026). Vendor material, cited only as a current instance of the interface.
Convai Innovations (2026). Laya model card and open implementation. Hugging Face, Apache-2.0. https://huggingface.co/convaiinnovations/laya (accessed 22 October 2026).