Introduction
modelARch is a product-modeling and software-generation environment. You describe the product as structured intent, refine its domain and experience, and generate a working implementation from that model.
The central idea is simple: the implementation should remain derivable from the product’s intent instead of becoming a second, increasingly implicit source of truth.
The problem
Section titled “The problem”Most generative tools optimize the first delivery. They turn a prompt or specification into code, then hand that code to a team to maintain normally. The first result may be fast, but every later change must recover intent from a growing implementation and preserve decisions scattered across it.
modelARch optimizes the sequence of changes. It keeps a structured, versioned model that captures:
- the domain and its vocabulary;
- actors, permissions, and ownership boundaries;
- actions, events, rules, and exceptional cases;
- journeys, views, navigation, and interaction decisions;
- brand and design-system intent;
- integrations, add-ons, and runtime requirements.
That model is validated and compiled by a versioned generator. A new product decision produces a new model revision and a new release candidate—not an invisible patch to old generated output.
The three layers
Section titled “The three layers”| Layer | Purpose | Examples |
|---|---|---|
| Evolutionary Model | Author product intent | Objects, permissions, rules, views, integrations |
| Generator | Translate supported intent | Backend, frontend, tests, contracts, manifests |
| Runtime | Operate live state | Data, configuration, infrastructure, telemetry |
These layers cooperate without pretending to be the same thing. The model does not contain live database rows. Infrastructure does not decide whether a field was renamed or replaced. Generated code does not become a hidden authoring surface.
What modelARch is not
Section titled “What modelARch is not”modelARch is not:
- a one-shot prompt-to-code wrapper;
- a visual editor that merely exports scaffolding;
- a bidirectional model/code synchronization system;
- an attempt to place every kind of production state into one file;
- a claim that generated software can operate without migrations, configuration, infrastructure, or observability.
It is an attempt to make product intent explicit enough that implementation can be regenerated safely throughout the product’s life.
Where to go next
Section titled “Where to go next”- Follow the Quickstart for the shortest end-to-end path.
- Read the Mental model before making architectural assumptions.
- Explore What you build to understand the outputs.
- Evaluate the complete Regenerative Software thesis.
Product and paradigm
Section titled “Product and paradigm”The terms are related but distinct:
- Regenerative Software is the paradigm and its operating contract.
- modelARch is an implementation of that paradigm: the authoring environment, model, validation system, generators, preview, and delivery workflow.
This documentation labels normative requirements as such and keeps current product support in the reference sections. That distinction matters: a sound idea should be testable independently of marketing, and a shipped feature should be described precisely rather than implied.