Amorphic Systems: How Outcome‑Driven Architecture is Realisable in the Age of Spec‑Driven Development

“A fluid, shape‑shifting digital architecture forming itself dynamically from glowing modular components, representing outcome‑driven systems. Abstract, futuristic, high‑contrast, soft volumetric lighting, deep blues and silver tones, clean geometric forms dissolving and reforming.”

Most systems are built backwards. We start with inputs, write logic, and push outputs somewhere predetermined . Even though the world we operate in changes constantly. But with the rise of spec‑driven development and machine‑interpretable intent, we finally have the tools to flip the model.

This article introduces amorphic systems: architectures that form themselves around outcomes, dissolve when finished, and reform differently when context changes. Not rigid pipelines. Not fixed workflows. But dynamic, collaborative, outcome‑driven systems.

If you are not yet a member of medium.

The Problem With Imperative Architecture

Traditional systems follow a familiar pattern:

Get input data -> Apply logic -> Write output somewhere

Even modern microservices and event pipelines still embed the “how” inside code. Logic decides where data goes. Workflows are fixed. Architecture is static.

This imperative framing locks systems into a shape that rarely fits evolving needs.

Outcome Thinking: The Inversion

Amorphic systems begin with a simple inversion:

Start with the desired outcome, not the steps. Let the system discover the logic and data required to produce it.

This mirrors how humans solve problems. If you need a best‑selling items report, you don’t personally gather all data and run all calculations — you collaborate, delegate, and iterate. Over time, the process evolves naturally.

Outcome thinking reframes problems as self‑solving structures.

Why Spec‑Driven Development Changes Everything

Spec‑driven development (SDD) gives us something we’ve never had before: machine‑interpretable intent.

A spec can describe: the desired outcome the shape of the output constraints (cost, latency, compliance, locality) optimisation targets acceptable sources acceptable transformations

Crucially, the spec is interpreted dynamically. The same spec can produce different workflows depending on: available tools available data sources current load cost conditions compliance rules performance targets

This is exactly what amorphic systems require.

How This Actually Works, Without the Jargon

Before the vocabulary, a plain example.

Order dinner through a food delivery app and you don’t specify a driver, a route, or the chef. You specify an outcome: “vegetarian, under 30 minutes, budget X”. The app works out which restaurant can meet that, which courier is nearest, and which route avoids the traffic tonight. Order the same thing tomorrow and you might get a different chef, a different courier, a different route — because the outcome stayed fixed while the means adapted to current conditions. Nobody redesigns the app each time a restaurant closes or a courier goes offline.

An amorphic system applies the same shape to software. The “spec” is the order: what you want, and the constraints it has to satisfy. The system’s job is to work out, right now, which data, which logic, and which infrastructure best satisfy that spec; then assemble them, run them, and let them go. Ask again tomorrow, under different conditions, and the answer can legitimately be different, without anyone having changed the request.

The rest of this article is about how a computer system does the same thing the delivery app does: locating the available options (identity), understanding what each one is good for (qualifiers), and being able to swap one for another without the requester needing to know or care (redirection). None of it is exotic once you see it as the same pattern already running in your phone.

Each idea is simple to state, though takes real work to do properly. This article introduces the shape of the ideas; later pieces in this series take each part in turn and give it the fuller treatment it deserves.

The Building Blocks of an Amorphic System

Uniform Access

All assets; data, logic, services, transformations, must be accessible through a consistent interface. Uniform access eliminates special cases and hidden coupling.

Identity + Qualifiers

Every asset receives a unique identity (URN, UUID, etc.). Qualifiers describe how it should be used: “Prefer real‑time data” “Minimise cost” “Use GDPR‑compliant sources” “Prefer RDBMS over CSV”

Identity tells the system what something is. Qualifiers tell the system how it should be used.

Redirection and Request Rewriting

The system must be able to: redirect requests to optimal assets rewrite requests to match execution environments substitute logic or data sources dynamically choose execution sites based on optimisation targets

This is how the system forms itself.

Logic as Identified Assets

Logic is not tied to services or locations. It is discoverable, relocatable, substitutable, and optimisable.

Catalogue of Capabilities

The system maintains a catalogue of: datasets logic functions transformation pipelines execution environments external services

This catalogue is the palette from which workflows are composed.

How an Amorphic System Behaves

An amorphic system does not execute a fixed workflow. Instead, it: receives an outcome request interprets constraints discovers relevant assets redirects and rewrites requests forms a workflow dynamically executes it dissolves it reforms differently next time

Architecture becomes a dynamic response, not a static design.

End‑to‑End Example: Generating a Sales Report in an Amorphic System

To illustrate how an amorphic system works in practice, consider a simple but representative task:

Generate a “Best‑Selling Items” report.

In a traditional system, this requires a fixed workflow. In an amorphic system, none of the steps are predetermined.

1 — Outcome Request

A user submits: Outcome: “Best‑Selling Items Report” Format: tabular dataset Constraints: real‑time data, minimise cost, GDPR‑compliant, downloadable output Optimisation Target: accuracy over latency

This is expressed as a spec, not a workflow.

2 — Dynamic Interpretation

The system asks: What datasets contain sales information? Which are real‑time? Which are compliant? Which transformations compute “best‑selling items”? Which execution environments are available? Which options minimise cost? Which options maximise accuracy?

Interpretation is contextual and changes over time.

3 — Identity Resolution

The system resolves identities such as: urn:data:sales:stream urn:logic:aggregate:top-items urn:exec:compute:cluster-eu

Each identity has qualifiers describing freshness, cost, locality, compliance, and performance.

4 — Redirection & Rewriting

The system rewrites the request: redirect data source → real‑time stream rewrite transformation → highest‑accuracy implementation redirect execution → EU cluster for compliance rewrite output → downloadable asset

This is the “self‑forming” behaviour.

5 — Dynamic Composition

The system assembles: real‑time data source dedupe logic aggregation logic EU execution site table formatter download delivery mechanism

A workflow is formed that did not exist beforehand.

6 — Execution

The workflow runs and produces the report.

7 — Dissolution

The workflow dissolves. No permanent pipeline exists.

8 — Reformation

Next time, the workflow may be different: new datasets cheaper compute more accurate logic new compliance rules different constraints

The system reforms based on the new context.

9 — Capturing Compositions

The system can capture the formed workflow: resolved identities selected assets validated optimisation path

This captured composition can be reused as long as the context remains valid.

10 — Automatic Invalidation

A composition is invalidated when: constraints change optimisation targets change new assets appear existing assets degrade compliance rules shift cost/performance conditions change

Invalidation triggers re-composition.

11 — Intentional Re-composition

Users can explicitly request re-composition: “Recompute using lowest‑cost options.” “Recompute using real‑time data only.”

This gives control when needed.

Composition Lifecycle Diagram

                         ┌──────────────────────────┐
                         │   Outcome Request (Spec) │
                         └──────────────┬───────────┘
                                        │
                                        ▼
                         ┌──────────────────────────┐
                         │  Dynamic Interpretation  │
                         │  (constraints + context) │
                         └──────────────┬───────────┘
                                        │
                                        ▼
                         ┌──────────────────────────┐
                         │   Identity Resolution    │
                         │ (data, logic, execution) │
                         └──────────────┬───────────┘
                                        │
                                        ▼
                         ┌──────────────────────────┐
                         │ Redirection & Rewriting  │
                         │ (optimisation + validity)│
                         └──────────────┬───────────┘
                                        │
                                        ▼
                         ┌──────────────────────────┐
                         │   Dynamic Composition    │
                         │ (workflow formation)     │
                         └──────────────┬───────────┘
                                        │
                                        ▼
                         ┌──────────────────────────┐
                         │        Execution         │
                         │ (produce the outcome)    │
                         └──────────────┬───────────┘
                                        │
                                        ▼
                         ┌──────────────────────────┐
                         │   Capture Composition    │
                         │ (cache for re‑use)       │
                         └──────────────┬───────────┘
                                        │
                                        ▼
                         ┌──────────────────────────┐
                         │   Re‑use Composition     │
                         │ (no recomposition needed)│
                         └──────────────┬───────────┘
                                        │
                                        ▼
        ┌──────────────────────────────────────────────────────────────┐
        │   Context or Constraints Change?                             │
        │   (new data, new logic, new rules, new optimisation target)  │
        └──────────────┬───────────────────────────────────────────────┘
                       Yes                                              No
                        │                                                │
                        ▼                                                ▼
        ┌──────────────────────────┐                     ┌──────────────────────────┐
        │   Invalidate Composition │                     │ Continue Using Captured  │
        │ (force recomposition)    │                     │ Composition               │
        └──────────────┬───────────┘                     └──────────────────────────┘
                       │
                       ▼
        ┌──────────────────────────┐
        │   Dynamic Recomposition  │
        │ (form new workflow)      │
        └──────────────────────────┘

Conclusion

Amorphic systems represent a shift from imperative, step‑driven design to collaborative, outcome‑driven architecture. With spec‑driven development, this shift is not only possible — it is inevitable.

By embracing identity, qualifiers, uniform access, dynamic composition, and contextual re-composition, we can build systems that adapt fluidly, optimise continuously, and solve problems in ways that resemble human collaboration rather than rigid automation.

The future of architecture is not fixed. It is amorphic.

It is going to take me a little time to write the articles, please bear with me, as I convert my notes and brain dumps, into articles. I’ve enrolled the help of AI to maintain focus, as my attention wanders, AI acts in a more typical manner.