Skip to content

Executable-Specification Interpreter

Runnable-specification engine (tool) — instantiates Specification-to-Execution Lowering

Runs the specification itself as the implementation — an engine that directly executes the what-level spec, so there is no separately generated code to drift out of sync with intent.

An Executable-Specification Interpreter removes the lowering gap by not lowering at all: instead of translating the specification into separate implementation code, it runs the specification directly. The spec is written in a language the engine can execute — a rule language, a formal operational model, a decision table — and the engine evaluates it against real inputs as the system's actual behavior. Its defining property is that the source of truth and the running artifact are the same object. There is no generated code downstream of the spec to fall out of sync, no translation step whose fidelity anyone must trust, and no question of whether the implementation matches intent — because the implementation is the intent, executed. The trade is deliberate: it buys perfect spec-to-execution fidelity at the cost of everything a general-purpose lowering exists to optimize.

Example

A team standardizing a messaging protocol writes its message-handling rules as an executable specification: a state machine plus guard conditions expressing exactly which message is legal in which state and what reply it produces. Rather than hand-code a server and hope it matches the document, they run the spec directly in an interpreter — feed it a sequence of incoming messages and it is the protocol, transitioning states and emitting replies by evaluating its own rules.

When a partner team asks "what should happen if a RESET arrives mid-handshake?", there is no argument over the prose: they send that sequence to the interpreter and read off the canonical answer. The same running spec later becomes the authoritative oracle that faster, hand-optimized implementations are checked against. But as the production server it would be far too slow — evaluating rules interpretively on every packet — which is exactly why a separately lowered implementation eventually exists alongside it, held to the interpreter's behavior rather than replacing it.

How it works

  • Execute, don't translate. The engine evaluates the specification's own constructs (rules, transitions, conditions) against inputs; the spec is loaded and run, not compiled into another language.
  • One artifact. Because the spec is the executable, a change to intent is a change to the running system in the same edit — nothing to regenerate, nothing to re-sync.
  • Authoritative by construction. Any question of "what should the system do here?" is answered by running the spec, which makes the interpreter a natural oracle.
  • Non-functional gap left open. The engine optimizes for fidelity and clarity, not speed, footprint, or platform fit — precisely the concerns a real lowering exists to address.

Tuning parameters

  • Specification expressiveness — how rich the executable language is. More expressive specs capture more intent directly but are slower to interpret and harder to analyze.
  • Execution transparency — whether each step is traceable and animatable or only produces a final answer. Transparent execution makes it a superb teaching and debugging oracle; opaque execution runs faster.
  • Performance investment — how much the interpreter is optimized. Left slow, it stays a clean reference; optimized, it blurs toward being the product and risks importing the very translation choices it was meant to avoid.
  • Substrate coverage — how much real-world messiness (I/O, concurrency, failure) the engine models versus abstracts away, trading realism against simplicity.

When it helps, and when it misleads

Its strength shows wherever being demonstrably faithful to intent matters more than running fast: exploring a design, animating a formal model, settling "what should happen" disputes, or serving as the golden oracle for optimized implementations. It eliminates an entire class of bug — the translation defect — by eliminating the translation.

Its failure mode is the mirror image of its strength: the executable spec is almost always too slow, too coarse, or too unportable to be the production system, so relying on it as the shipped implementation stalls under real load or cannot meet the platform's non-functional demands.[1] The misuse is treating a reference interpreter as the product and discovering at scale that fidelity was never the binding constraint — throughput was. The discipline is to use the interpreter for what it is uniquely good at — authority and disambiguation — and to lower it to an optimized implementation for production, then hold that implementation to the interpreter with a Differential Equivalence Test.

How it implements the components

Executable-Specification Interpreter fills exactly the two components that collapse into one object when the spec is run directly:

  • source_intent_specification — it holds and operates the what-level spec as a live artifact; the specification is loaded and evaluated, not merely referenced from a document.
  • executable_realization — the spec, executing, is the realization; the how is the what, run — so unlike a Compiler Intermediate-Representation Lowering Pipeline, there is no separately emitted artifact.

Everything a real lowering adds is deliberately absent: it emits no distinct target code through staged passes (a Compiler Intermediate-Representation Lowering Pipeline or Model-Driven Code Generation), states no separate correspondence contract (semantic_correspondence_contract — Proof-Carrying Transformation), and profiles no target substrate (target_substrate_profile — Hardware or Controller Synthesis); the interpreter's whole point is that it needs none of them.

Notes

Because the running spec is authoritative by construction, its highest-value downstream use is as the oracle for a lowered production implementation — the reference side of a Differential Equivalence Test. Keeping the slow-but-faithful interpreter alongside the fast-but-derived implementation is how a team gets both fidelity and performance without having to choose.

References

[1] An executable specification is a spec written so it can be run rather than only read, letting a specification double as a runnable reference. Its recognized limitation is that fidelity and clarity — not performance — are its design goals, so it typically serves as oracle and design tool rather than as the production system. ↩