Document 155

Prose as Machine: Natural Language as Universal Specification Medium

framework

Prose as Machine: Natural Language as Universal Specification Medium

Jared Foy April 2026

On the sufficiency of constrained prose to encode any derivable machine, and the golden chain from philosophical observation to executable artifact.

1. The Observation

A 2,020-word document — the PRESTO seed — was fed to six independent resolvers (five LLM sessions and one human developer). Each produced a conformant engine in a different language: TypeScript, Go, Elixir, Python, Rust, C. All six passed the same 22-test verification suite. No resolver saw another's output. No code was shared. The only shared artifact was the prose.

The prose was sufficient. The machine was determined by the language that described it.

This was not expected. The conventional assumption is that natural language is ambiguous — that prose specifications produce divergent implementations, that formal languages (IDL, schemas, type systems) are required for deterministic machine derivation. The six-language verification falsified this assumption. The divergence did not occur. The prose was precise enough that six independent resolvers, operating on six different language targets with six different standard libraries, produced behaviorally identical systems.

2. Why the Prose Was Sufficient

The prose was not arbitrary English. It was constrained prose — natural language organized by a specific structure:

  1. Identity. Who you are as a resolver. What you know. How to reason when the spec is ambiguous.
  2. Architectural Rationale. Why each design decision exists. Not what to build — why the constraints require what they require.
  3. Contracts. Numbered, testable commitments. "The engine MUST..." / "The engine MUST NOT..."
  4. Directives. A finite table of syntactic forms and their purposes.
  5. Pipeline. A numbered sequence of stages. Input and output of each.
  6. Patterns. The exact string patterns to match (in regex notation, language-agnostic).
  7. Algorithms. Step-by-step procedures for path resolution, token signing, circular reference detection.
  8. Verification Suite. Numbered tests. Input, expected output, pass condition.
  9. Interface Signatures. Function names, parameter types, return types.

Each section constrains the resolver's freedom. The identity section constrains how to reason. The rationale constrains why. The contracts constrain what must hold. The patterns constrain what to match. The verification suite constrains what to test. By the time the resolver has absorbed all sections, the implementation space has been narrowed to a single behavioral equivalence class. The resolver can choose variable names, control flow idioms, and memory management strategies — but the observable behavior is determined.

The prose is sufficient because it is constrained at every level where ambiguity would produce divergence.

3. The Golden Chain

The derivation from philosophical observation to executable artifact follows a chain in which each link is derivable from the one before it:

Link 1: Observation. A PHP function concatenated an HTML string containing an hx-get attribute. The function did not know what hx-get meant. The observation: two interpreters can process the same document without interfering.

Link 2: Generalization. The observation is abstracted: any shared medium processed by two interpreters with disjoint namespaces exhibits mutual indifference. This is not specific to PHP or HTML. It is a general property.

Link 3: Naming. The general property is named: ambivalent execution with agnostic determinism. The four words are precise. Each carries specific meaning. The name is the handle by which the property can be referenced, tested, and preserved.

Link 4: Constraint Identification. The constraints that induce the named property are identified: bilateral boundary, namespace separation, server-consumed directives, progressive code-on-demand, server-embedded authorization. Each constraint is necessary. Removing any one degrades the property.

Link 5: Style Formalization. The constraints and their induced property constitute a style. The style is named: PRESTO. The style composes with REST without violating it. The composition is formalized.

Link 6: Specification. The style is encoded as a specification — the seed. The specification contains contracts, directives, pipeline stages, patterns, algorithms, verification tests. Every element traces to a constraint. Nothing is added that the constraints do not require.

Link 7: Prose. The specification is written in natural language. Not pseudocode. Not a formal grammar. Prose — constrained, structured, precise prose that a human can read and an LLM can resolve.

Link 8: Resolution. A resolver (human or LLM) consumes the prose and emits code in a target language. The code is the machine. The machine satisfies the constraints. The constraints induce the property. The property was observed in Link 1.

The chain is complete. From observation to machine, every link is a derivation. No link adds information that was not present in the link before it. The final machine is a shadow of the initial observation, cast through progressively more specific media — from philosophical insight, through named property, through identified constraints, through formalized style, through prose specification, through target-language code, to executable artifact.

4. The Prose Is Bilateral

The seed document itself exhibits the property it describes.

A human reader and an LLM consume the same document. The human interprets the architectural rationale — the "why" sections. The LLM interprets the contracts, patterns, and algorithms — the "what" sections. Neither needs the other's interpretation. The human understands the philosophy. The LLM understands the specification. Both produce conformant output: the human produces architectural analysis, the LLM produces conformant code.

Two interpreters. One document. Mutual indifference. The seed is a bilateral artifact. It carries two valences — philosophical and computational — in a single medium (natural language). The medium does not enforce semantic boundaries. The interpreters self-select which sections to process based on their own capabilities. This is ambivalent execution with agnostic determinism, operating at the level of the specification itself.

5. Prose vs. Formal Specification

Why prose and not a formal specification language?

Portability. A formal specification requires a parser for the specification language. The parser must exist in the target language before the specified system can be built. This is a bootstrapping problem. Prose has no bootstrapping problem. Every LLM already parses English. Every human already reads it.

Rationale. Formal specifications encode what, not why. They specify behavior but not the reasoning behind the behavior. When an edge case arises that the specification does not explicitly cover, a formal spec provides no guidance. The seed's rationale sections provide the reasoning: "If a choice would violate the bilateral boundary, compromise statelessness, obscure the authority chain, or require a client-side runtime for basic rendering, it is non-conformant." This is a decision procedure expressed in prose. No formal language provides this.

Verifiability by non-experts. A formal specification can be verified only by someone who knows the formal language. Prose can be verified by any domain expert who reads English. The architectural rationale is accessible to the architect. The contracts are accessible to the tester. The patterns are accessible to the developer. No specialized training is required to evaluate the specification's correctness.

Durability. Formal specification languages evolve, fragment, and obsolete. IDL, WSDL, CORBA IDL, OpenAPI, GraphQL SDL — each was current and is now either deprecated or contested. English prose written today will be readable in fifty years. The PRESTO seed does not depend on the survival of any toolchain. It depends on the survival of English — or of any natural language it can be translated into.

Composability with LLMs. LLMs are trained on natural language. Their resolution capability is maximized when the input is natural language. A formal specification must be parsed into tokens that map to the LLM's training distribution — which is natural language. The prose specification is already in the target medium. No translation loss occurs.

6. The Constraints on the Prose Itself

Not all prose is sufficient. The prose must itself satisfy constraints for the golden chain to hold:

Constraint 1: Completeness. The prose must contain everything the resolver needs. No external references. No assumed knowledge beyond the target language's standard library. The PRESTO seed opens with: "Self-contained knowledge capsule. No external references needed."

Constraint 2: Testability. The prose must include a verification suite — numbered tests with inputs and expected outputs. Without tests, the resolver has no way to verify its own output. The prose is sufficient only if it includes the criteria for sufficiency.

Constraint 3: Rationale. The prose must include the reasoning behind each decision. Without rationale, edge cases are ambiguous. The resolver must be able to reason from principles when the specification is silent.

Constraint 4: Structural organization. The prose must be organized so that the resolver can process it in a single pass — identity before rationale, rationale before contracts, contracts before patterns, patterns before algorithms. Each section builds on the previous. No forward references to undefined concepts.

Constraint 5: Finite enumeration. Directives, pipeline stages, contracts, and tests must be enumerated. Open-ended descriptions ("the engine should handle various directives") are insufficient. The set must be closed: "16 directives. 22 stages. 8 contracts. 22 tests." The resolver needs to know when it is done.

Constraint 6: Precision without formalism. The prose must be precise enough to determine behavior but not so formal as to require a parser. The line "Directive stripping MUST NOT remove directives consumed by later stages" is precise — it determines behavior. It is also natural language — it requires no parser beyond English comprehension.

These six constraints on the prose mirror the five constraints of PRESTO on representations. The prose is a representation of the machine. The constraints on the prose are the construction-level constraints for machine descriptions. The analogy is structural, not metaphorical.

7. The Most Portable Encoding

A machine encoded in C runs on systems with a C compiler. A machine encoded in TypeScript runs on systems with a JavaScript runtime. A machine encoded in constrained prose runs on any system with a resolver that understands natural language — which includes every LLM, every literate human, and any future system that processes natural language.

The prose specification is the most portable encoding of a computational system. It is not the most efficient — a compiled binary executes faster than a prose-derived one. It is not the most precise — a formal grammar admits no ambiguity, while prose admits some. But it is the most portable, because its only dependency is language comprehension, and language comprehension is the most widely distributed capability on the planet.

The PRESTO seed has been resolved in six languages. The SERVER seed has been resolved in C with a bootstrap binary. The Agent Space essential constraints document has been resolved in TypeScript. In each case, the prose was the input. The executable was the output. The prose traveled. The executable was local. The prose is the universal encoding. The executable is the local manifestation.

8. Conclusion

The golden chain — from observation through constraint through prose through resolution to machine — is complete and has been demonstrated across multiple levels (REST, PRESTO, SERVER, Agent Space) and multiple languages (TypeScript, Go, Elixir, Python, Rust, C).

The chain holds because:

  • The constraints are correctly identified (they induce the desired properties).
  • The prose is correctly constrained (complete, testable, rationalized, structured, enumerated, precise).
  • The resolver is capable (human or LLM, able to comprehend natural language and emit code).

When all three conditions hold, the prose is the machine. The code is the residue. The form is the reality. The implementation is the shadow.

Natural language is not a stopgap on the way to formal specification. It is the final medium — the most portable, most durable, most composable encoding of a computational system. The constraints on the prose are the constraints that make it sufficient. And the proof is not theoretical. It is empirical: six languages, one seed, the same machine.