The Language Between Languages

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. Both sentences are clear. Together they are not, and the problem lives in one word. If a job’s first attempt fails and is retried, has the job been executed twice? It depends what “executed” means. It could mean an attempt: any time the code runs. It could mean a completed job: a run that finished and counted. Or it could mean an externally committed effect: an email sent, a card charged. Under the first reading the two requirements contradict each other. Under the second or third they sit together comfortably.

Someone building the queue has to choose. Say they take the second reading: at most one completed execution per job. They write it down in a form a tool can check, and the tool checks it perfectly. Every property holds. And then it turns out the owner meant the third reading, because the thing they were afraid of was a customer being charged twice. The verification was flawless. It verified the wrong thing.

This chapter is about that situation, and about the wide space of representations that lies between a person saying what they want and a machine being able to check or run it. The last chapter asked what must survive a transformation. This one asks how to express what must survive, and how to express relationships, constraints and meanings, when both people and machines have to use them.

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 write it down in progressively more explicit forms. Each step is a different representation of roughly the same intent.

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  completed executions per job  <=  1
    R2  retries per job, cause = transient  <=  3

schemas and constraints
    fields: job_id, attempt, status, cause
    constraint: count(status = completed, by job_id) <= 1

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 go down the page. The wording gets narrower. Fewer interpretations are possible, and the choice of meaning for “executed” is forced into the open at the structured step, because you cannot write the count without deciding what to count. A tool can check more of it. More of it can drive a machine. And the person who started the conversation can recover less of it unaided: the last rungs are not things the product owner could read and confirm.

This is a ladder in the sense that each rung is more explicit than the one before. It is not a ranking. The point of laying it out is to see what each rung is good for, because a good deal of confusion in this area comes from treating the ladder as a staircase up to something better.

Six things to ask of any rung

Six questions can be asked of any representation, and they pull against each other.

Natural prose scores high on expressiveness and reconstructability and low on checkability. A formal specification scores high on checkability and low on reconstructability for most people. Neither is better. They answer different needs, and a representation that is excellent on one axis is usually paying for it on another.

Intent preservation sits oddly in the list, because it is the one the other five do not settle. It is not a property of the representation alone. It is a relation between the representation and a person’s purpose, and it can only be judged by asking the person, or by something that stands in for them.

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 is valuable. It forces decisions, and forced decisions surface ambiguities that prose let everyone ignore. That is a real gain. But a decision has been made, and someone made it. In the queue example, the person who wrote the structured requirement chose a meaning for “executed”, and in making the requirement checkable they removed the other two. If that choice was wrong, the formal version is not merely incomplete. It is confidently, checkably wrong, and its precision lends it authority the prose never had.

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 that satisfies a specification has shown conformance to that specification. It has shown nothing about whether the specification captured what the person meant. A property that has been tested within a bounded set of cases, a property that has been proved under stated assumptions, and a property that is the one the person actually intended are three different things, and an assurance on one is no assurance on the next. A proof about a model that quietly leaves out some of the work is a valid proof. It simply does not cover what the person wanted covered.

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 the work in steps. The person states what they want in prose. The system points out where the prose can be read more than one way, and says so in the person’s own words: “execution” here could mean an attempt, a completed job or an external effect. It proposes a more explicit version, with each interpretive choice tied to the words in the original that prompted it. The person accepts it, repairs it or defers the decision. Mechanical checks run only on what has been settled. And the system explains the checked version back in plain language, so the person can see whether it still says what they meant.

Each step from prose toward something more explicit can then be described in terms the book already has. The new version may preserve the original, narrow it, expand it, drop part of it, contradict it, or leave it still ambiguous. Those are the same questions as survival, loss and addition from the previous chapter, asked of a translation. The aim is not a perfect translation but one whose losses and choices are visible and open to correction.

Whether that works is an open question, and a good one. It could turn out that the labour of reviewing the system’s proposals is simply the labour of formalising by hand, moved somewhere else. It could turn out that checkable representations raise people’s confidence without improving how well the result matches what they wanted. Those would be important to find out, and nothing here assumes the answer.

Machines as an audience

There is a reason this belongs in a book about communication. Until recently, nearly everything people wrote was for other people. Increasingly, communication is partly between people and machines, and the machine is not a passive reader. It acts on what it is told. That changes what a representation is for.

A representation written for people can afford to be ambiguous, because people repair ambiguity with context and purpose, as an earlier chapter described. A representation that a machine will act on cannot rely on that repair. Somewhere on the ladder it has to become explicit enough to constrain behaviour, and the explicit version belongs to a different register of language. Call it the language between languages: the representations through which human intent is carried into forms machines can check and act on, and, in the other direction, through which machine state is carried back to people.

Further down the ladder lies something stranger. The last rung, machine-native operational state, was never meant to be read by a person at all. Its quality is judged by what it does. A person’s only way to relate to it is through a more readable representation higher up, and the whole arrangement depends on the connections between rungs being trustworthy. If those connections are weak, the human has authorised something they cannot inspect. Much of the later argument of the book, about delegation and about machines communicating with machines, returns to this.

Words at the boundary

Return to the word “executed”. A system could stop treating it as a word and expose the choice as a decision with declared options:

"executed" means:
    attempt
    completed job
    external effect

The value is that the selected interpretation becomes something a machine can check, and no downstream component can quietly invent a fourth reading. That is a real gain over prose. It does not show that the right option was chosen, or that the choice was bound to the right passage of the owner’s request.

Classifying text into labels is an old idea, and so are scoring a fixed set of labels, constrained decoding, reranking, calibration and cascades of cheap and costly models. What is recent is the exposure of this as a general, software-facing interface: the caller declares the options, and the system returns a choice or a probability for each, without a paragraph in between. Jev is one current commercial instance and Laya an open implementation. A bounded decision model that predicts YES, NO or TBD, and learns when to defer instead of applying a threshold afterwards, appeared earlier (EvaluatorDPT). An early evidence audit places the typed-decision interface among these older ideas and finds no clear accuracy advantage over label-probability readouts, with advantages in latency and cost. Nothing here depends on what is inside any of these systems, which for Jev is not public.

The result that matters for this chapter concerns the options’ names. Sun and colleagues report, in the setting they evaluated (1,200 workflow decisions), that renaming the two options of a binary decision from 0/1 to no/yes, with the definitions bound to them unchanged, changed 70.4 more answers per hundred (95% interval 67.6 to 73.1). Discrimination, measured by AUC, fell from about .94 to .23, and the type-error rate stayed at 0%. The answers remained perfectly well formed. Their operative meaning had been reversed.

Apply that to the queue. attempt, completed job and external effect are not neutral display strings. The study suggests that, in a system like the one it evaluated, their ordinary associations can override the definition written beside them, and a response can satisfy the schema while violating what the schema was meant to say. The magnitude belongs to that study; what carries over is the risk, and it is one more instance of the distinction the chapter has been drawing:

type conformance  ≠  semantic correctness

A typed interface is the most explicit rung on the ladder only when the binding between option name, definition, source evidence and selected result stays inspectable.

Context Language Models point at where such decisions would be asked. Shao and colleagues describe models that manage their own context by treating it as a file they may edit, and report prompted and reinforcement-learned variants. The part that bears on this book is the context file: working state that persists between turns, is written in text and is revised as the work goes on. That is close to the semantic record of Chapter 7, which a plugin could keep as a plain, editable text file. The trained variants are another matter; a plugin cannot reproduce them by managing state. The roles stay distinct:

maintained state:  what currently applies
typed decision:    a bounded question asked of that state
renderer:          an optional human-facing presentation

A typed decision can consume maintained state, and can classify or route an update to it. It cannot certify that the state kept what the conversation meant. A maintained state is not verified meaning (maintained context ≠ verified meaning), and a typed decision is not thereby a correct one (typed decision ≠ correct decision). Whether the state preserved the conversation is a question of reconstruction. A sentence generated afterwards to explain a decision is likewise not a record of its cause (generated explanation ≠ causal record).

One adjacent line of work should be named and bounded. Research on continuous latent states and on sentence-level representations shows that not every internal operation of a model has to be rendered as prose. That concerns model architecture. It says nothing about whether a plugin’s external state preserved meaning, and it is not the basis for anything proposed here.

Where this leaves us

There is a ladder of representations between ordinary language and executable machine state: prose, controlled prose, structured requirements, constraints, executable contracts, state-transition models, formal specifications and operational state. Each trades expressiveness, ambiguity, checkability, intent preservation, executability and reconstructability differently, and none is simply better. Making a statement easier to check can make it worse at preserving what was meant, so intent preservation, checkability and conformance must be kept apart. A typed decision over declared options is the most explicit form of this: useful only while the binding between option name, definition and source stays visible. A mediator’s role here is to help a person move between rungs with every interpretive choice visible and correctable.

The chapters so far have built the parts. What must survive a transformation has an answer in plain language. The question of how to express it, when machines are involved, now has a map. What is left is to see whether the parts fit together: whether a system can take a source, interpret it, choose a representation for a task, add what belongs beside it and check what survived, without the machinery getting in its own way. That means building one.

References

• 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.
• 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., Shi, J. & Yang, Z. (2026). Type-Safe Is Not Error-Free: A Constrained Decision Head Follows the Option Name, Not the Rubric Bound to It. arXiv:2609.26758. (Cited for one reported result in the setting the authors evaluated; the magnitude is not generalised.)
• TypeSafe AI (2026). Jev product description. 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.