Software is usually treated as the thing that exists now.

The files. The current UI. The current backend. The current module boundaries. The current language. The current implementation.

But that is only one answer.

A more interesting way to see software is as a possibility space: the set of all programs that would still satisfy the same constraints.

That sounds abstract, but it is close to how procedural generation already works.

In wave function collapse, the output is not arbitrary. A tile can be placed only when it satisfies the neighboring constraints. The generator does not know one finished world in advance. It knows the rules that make a world valid, then it collapses one valid arrangement.

Software can start to work the same way.

| Layer | What Must Stay True | What Can Vary | | --- | --- | --- | | Identity | same feature, action, state, and public contract | React surface, SwiftUI surface, CLI workflow | | Behavior | same effect boundaries and observable workflow | component shape, route shape, worker shape | | Runtime | valid host, capability, performance, and proof limits | local-first view, native adapter, plugin mount | | Projection | idiomatic target output with explicit losses | target language, file layout, interface form |

The current implementation is a collapsed answer. The deeper source is the constraint system that defines which other answers would still be valid.

The Current Code Is A Collapse

Files are a realized state.

They choose one language, one framework, one directory layout, one UI shape, one set of APIs, one deployment model, one ownership boundary.

That choice matters. The code has to run.

But the code is not the whole meaning of the system.

The meaning lives in constraints:

the checkout action must preserve payment authority
the list must keep stable item identity
the public User contract must not change silently
the workflow must remain keyboard operable
the storage effect must stay inside a declared capability
the native projection must preserve ownership or report loss

Once those constraints are explicit, the current implementation becomes one valid arrangement among many.

That is the difference between rewriting software and reshaping it.

Shapeshifting Needs Boundaries

Shapeshifting software is not software that can become anything.

That would be useless.

The valuable version is software that can change form because it knows what must not change.

Some constraints are hard:

preserve the public API
do not widen an effect
do not drop an auth policy
do not claim a runtime proof without telemetry

Some constraints are preferences:

prefer native controls on iOS
prefer smaller bundles on low-end devices
prefer local execution when data is private
prefer a split module when it reduces merge pressure

That distinction matters.

If a hard constraint fails, the shape is invalid.

If a preference loses, the shape may still be valid. It is just not the best collapse for this situation.

Merge Is Constraint Satisfaction

A semantic merge is not only combining edits.

It is asking whether there exists a program that satisfies the base constraints plus both branches.

base:
  User.fullName is the public display identity
 
branch A:
  rename name -> fullName
 
branch B:
  add displayName(user)
 
merge question:
  is there still a valid program where displayName points at the preserved identity?

Text merge sees overlapping lines.

Semantic merge sees constraints:

identity preserved
binding rebased
public contract unchanged
type gate passed
runtime proof unchanged

If those constraints can all be satisfied, the merge is not lucky. It is admitted.

If a proof is missing, the system should fail closed and turn the refusal into new work.

That makes merge less like conflict resolution and more like constraint solving.

Translation Is A Generated Projection

Translation is the same idea with a different output.

React to SwiftUI is not a string rewrite. TypeScript to Rust is not a clever pretty-printer. JSX to HTML, CSS, and JavaScript is not only syntax lowering.

Each target is a projection that must satisfy the source constraints in a different world.

constraintSpace CheckoutSurface @id("space_checkout") {
  subject action_checkout
  target react
  target swiftui
  target html-css-js
 
  variable surface kind projection domain react|swiftui|html-css-js default react
  hard identity kind semantic-identity subject action_checkout preserve action|state|effect failClosed
  hard policy kind capability subject payment.authorize evidence auth_gate
  preference native kind platform-idiom target swiftui weight 0.8 reason "prefer native controls on iOS"
  collapse mobileCheckout strategy evidence-first target swiftui requires identity|policy|runtime_probe produces view_checkout_mobile
  admission mergeSafe kind semantic-merge status open requires hardConstraints|runtimeProof failClosed
}

That file is not saying “generate anything.”

It is defining a valid space:

these outputs may vary
these identities must survive
these effects must stay bounded
these proofs must exist
these targets are allowed
these preferences guide selection

The output is a collapse of that space into a concrete artifact.

Refactoring Becomes Search

This also changes refactoring.

A refactor is usually described as changing structure without changing behavior.

But in a constraint-space model, a refactor is a search for a better arrangement.

Better for what?

more parallel work
fewer merge hotspots
clearer ownership
smaller runtime surface
stronger type boundary
cheaper model context
more local execution

The system can ask for another valid shape:

keep behavior fixed
keep public API fixed
reduce correlated edits around these symbols
split effects away from pure logic
emit a new module layout
prove the gates still pass

That is not just cleanup.

It is optimization over the future coordination cost of the codebase.

Runtime Adaptation Is Partial Collapse

The same model applies at runtime.

An application could choose a different valid shape depending on the device, permissions, latency, data locality, or user intent.

Not by hallucinating an interface.

By selecting from a declared possibility space.

private data -> local-first view
screen reader active -> accessible layout projection
low bandwidth -> compact workflow
admin role -> expanded control surface
mobile device -> native interaction shape
automation client -> tool/action projection

The app is still governed by constraints.

It can adapt because adaptation is no longer a pile of special cases. It is a controlled collapse of a semantic space.

The Source Is The Space

The deeper claim is this:

The source of truth is not the current code.

The source of truth is the constraint system that makes the current code one valid answer.

That does not make implementation less important. It makes implementation less lonely.

Files still matter. Compilers still matter. Tests still matter. Runtime probes still matter. The collapsed artifact has to work.

But the artifact becomes replaceable in a way it was not before.

A program can have several bodies:

web UI
native UI
CLI
plugin surface
agent tool
worker
database projection
test harness
documentation

Those bodies can all be different while preserving the same declared meaning.

That is where the idea gets large.

Software stops being one fixed shape and starts becoming a governed space of possible shapes.

Semantic merge is one operation over that space.

Translation is another.

Refactoring is another.

Runtime adaptation is another.

And the thing that makes all of them serious is the same thing that makes procedural generation work:

not freedom from constraints, but enough constraints to safely create something new.