Language-agnostic design — one model, many implementations

2026-03-02 02:44:14.919Z

A well-formed NEXUS design produces artifacts that
describe what a system does, not how any particular
language implements it. The target language is a
parameter passed to the rendering layer — not a
constraint baked into the design. This is not an
aspiration. It is a property of the methodology
when applied correctly.

Why Designs Are Language-Agnostic

The core elements of an Event Model — Commands,
Events, Projections — are concepts, not code. A
command is a function that takes input and produces
an event. That description is true in F#, in
JavaScript, in Haskell, in Kotlin, in any language
with functions. The concept does not belong to
any language.

A spec built on top of that model describes inputs,
outputs, rules, and constraints at a semantic level.
"The quantity field must be a positive integer" is
a constraint. How F# expresses that constraint
through its type system is a rendering decision —
a correct one, and the one NEXUS currently makes —
but a decision made at render time, not design time.

When design and implementation concerns are
properly separated, the design is language-agnostic
by default. If a spec is so language-specific that
it could only be implemented in one language,
design and implementation concerns have leaked
into each other. The spec is incomplete as a
design artifact.

The Rendering Model

Implementation within NEXUS is rendering — the
translation of an approved, language-agnostic
spec into a specific target language following
the patterns and conventions of that language
and NEXUS's prescribed approach within it.

The render target is a parameter:

Approved Spec + Target Language → Implementation

Changing the target language does not require
redesigning. It requires re-rendering. The spec
is unchanged. The rendering AI is given a
different target. The output is a correct
implementation in the new language.

NEXUS and F#

NEXUS currently targets F# as its primary render
target. This is a deliberate choice — F#'s type
system, functional paradigm, and discriminated
unions align directly with NEXUS principles in
ways that make the rendering both natural and
correct.

F# is the language in which:

Invalid states are made unrepresentable through
types and smart constructors
Event types are modeled as discriminated unions
Commands and projections are pure functions
Pattern matching over events is exhaustive and
compiler-checked

These properties are not incidental to NEXUS —
they are why F# was chosen. The rendering AI for
NEXUS F# is trained and tuned to produce code
that takes full advantage of these properties.

But F# is the current render target. Not the
only possible one.

Multiple Implementations From One Design

Because the design is language-agnostic, the
same approved spec can be rendered into multiple
target languages simultaneously. One design.
Multiple correct implementations. Each faithful
to the spec. Each idiomatic in its target language.

This has several practical implications:

Portability — a system designed in NEXUS
is not locked to F#. If circumstances change —
a team that knows JavaScript, a platform that
requires JVM languages — the design remains
valid. Only the render target changes.

Verification — two implementations of the
same spec in different languages, both passing
the same acceptance criteria against the same
example data, provide strong mutual verification.
If they agree, the spec is correctly implemented.
If they disagree, one has a rendering error.

Education — the same design rendered in
multiple languages shows exactly what is
language-specific and what is not. The concepts
are visible in the design. The idioms are visible
in the renderings. The comparison is instructive.

Reverse Engineering and Language Migration

The language-agnostic property extends to reverse
engineering. An existing system in any language
can have its implicit design made explicit as a
NEXUS Event Model. That model is then language-
agnostic. It can be rendered into F# — or any
other target — producing a new correct
implementation from the derived design.

This enables principled language migration: not
a line-by-line port that carries all the original
language's idioms and assumptions into the new
one, but a design-level extraction followed by
a clean rendering in the target language. The
result is idiomatic in the target language
because it was rendered from a language-agnostic
design, not translated from the source language.

See: NEXUS → Insights → Reverse engineering
existing software with Event Modeling.

A Test of Design Quality

Language-agnosticism is a useful test of whether
a spec is complete and correctly separated from
its implementation. The test is simple:

Could this spec be implemented correctly in a
language other than F#?

If yes — the design is properly separated.
The spec describes what; the rendering decides how.

If no — implementation concerns have leaked into
the design. The spec contains F#-specific
assumptions that should be rendering decisions.
The design needs to be separated further.

This test can be applied during spec review
without actually producing a second implementation.
It is a thought experiment that surfaces
prematurely implementation-specific design
decisions before they become embedded.