Skip to content
modelARchmodelARch

The Regenerative Software thesis

Normative contract

Regenerative Software is software whose managed implementation remains reproducible from a versioned model of product intent, a versioned generator, and declared evolution inputs—without depending on hidden edits to earlier generated output.

The thesis

Section titled “The thesis”

Most software generators treat generated code as the final authority. After the first delivery, teams edit that code and the original prompt or model becomes background documentation. Every later change must reconstruct intent from an implementation that keeps accumulating decisions.

Regenerative Software inverts that relationship:

  • product intent lives in an explicit Evolutionary Model;
  • a deterministic, versioned generator compiles that model into managed artifacts;
  • persistent data evolves through explicit migrations;
  • secrets and runtime configuration travel through a separate control plane;
  • every delivery is an immutable, traceable release;
  • production is operated through releases, data, configuration, and infrastructure—not by editing managed files;
  • a permanent correction changes the model or generator and propagates through the same pipeline.

The model evolves. The software regenerates. The data migrates. Releases are promoted. Production is operated.

AuthorityEvolutionary Modelrevision n
validate→
CompilerGeneratorversion v
materialize→
EvidenceReleaseartifacts + manifests
promote→
Observed stateRuntimedata + config + infra

The Evolutionary Model

Section titled “The Evolutionary Model”

An Evolutionary Model is a living, structured, versioned, and validatable representation of product intent. It captures the perspectives needed to derive the product:

  • domain structure, behavior, rules, and lifecycle;
  • actors, permissions, ownership, and scope;
  • journeys, views, navigation, and interaction behavior;
  • presentation and design-system intent;
  • integration ports, callbacks, and external contracts;
  • prefab capabilities such as auth, notifications, files, and audit;
  • runtime topology choices with implementation consequences;
  • semantic evolution intent such as rename, split, merge, or transformation.

It is evolutionary because accepted change creates an immutable new revision related to its parent. It is not a brief that freezes before development starts.

The generated boundary

Section titled “The generated boundary”

The paradigm distinguishes:

  • Managed code: owned by the generator and replaceable on regeneration.
  • Extension code: owned by the user in explicit, stable surfaces the generator never overwrites.
  • Forked code: exported output that the user chooses to evolve directly, outside the regenerative contract.

This avoids the failed promise of round-trip engineering. model and managed output do not compete for authority.

The system is larger than the model

Section titled “The system is larger than the model”

Conceptually:

Artifact(n) = Generator(v)(Model(n), History(n-1), Stack(n), AddOns(n))


Release(n) = Artifact(n)
           + Migrations(n)
           + Configuration manifest(n)
           + Validation evidence(n)


Live system(t) = Active release
               + Live data(t)
               + Runtime config and secrets(t)
               + Infrastructure state(t)
               + External-service state(t)

The model is authoritative for functional and experiential intent. It is not authoritative for a password, a customer-created row, current CPU utilization, or whether a provider is presently available.

Ten invariants

Section titled “Ten invariants”

An implementation can claim the paradigm only if it preserves these properties:

  1. The model governs intent. Managed behavior that must survive regeneration is represented or deterministically derived.
  2. Managed code does not accumulate decisions. It is not a permanent authoring channel.
  3. The generator does not guess silently. Missing intent is requested, resolved by a visible default, or blocks generation.
  4. Every delivery is traceable. Revision, generator, artifacts, migrations, configuration requirements, and evidence are linked.
  5. Data is never treated as disposable code. Its transition is explicit and recoverable.
  6. Applied migrations form forward history. Recovery uses compatible releases or a new forward repair.
  7. Divergence is never silent. Managed-file, schema, config, or release drift blocks or becomes visible operational state.
  8. Failure preserves a known-safe state. Pipeline transitions are idempotent, resumable, and cannot promote an incomplete candidate.
  9. Operating is not editing. Recovery uses traffic, configuration, capacity, replay, repair, restore, or release promotion.
  10. Exit is explicit. Users own the artifacts and may fork them, but the fork is no longer falsely labeled model-governed.

What determinism proves

Section titled “What determinism proves”

For the same declared inputs, a generator should produce semantically equivalent managed artifacts. This makes defects reproducible and allows one shared fix to repair a class of applications.

Determinism does not prove that the model is correct, that the generator is complete, or that production is healthy. Those properties require validation, capability boundaries, tests, migrations, release controls, and observability.

The robustness claim

Section titled “The robustness claim”

The paradigm is robust when it can classify every material change or failure by authority and has a safe transition for it. It is not robust merely because regeneration is cheap.

Read next: