Discover
Explore the problem, actors, vocabulary, rules, exceptions, and unresolved decisions.
Model the product. Regenerate the software.
Turn product intent into software you can evolve, regenerate, validate, and deliver without making generated code a second source of truth.
One model · many verified projections
From product intent to running software
Section titled “From product intent to running software”modelARch is an environment for discovering a product, modeling its domain and experience, and compiling that intent into a working application. The model remains authoritative; generated artifacts remain replaceable.
Design
Turn intent into journeys, views, interaction patterns, brand, and experience decisions.
Generate
Validate one model and compile it into application, tests, contracts, and delivery artifacts.
Operate
Promote immutable releases while data, configuration, infrastructure, and telemetry keep their own authority.
Choose your path
Section titled “Choose your path”I want to understand modelARch
Learn the core concepts, the workflow, and what the platform produces. Start with Introduction and Mental model.
I want to model a product
Capture areas, objects, actors, actions, events, rules, queries, and integrations. Go to Modeling overview.
I need to evaluate the paradigm
Read its invariants, authority boundaries, migration strategy, release protocol, and incident model. Open Regenerative Software.
I need operational answers
Understand delivery channels, configuration, secrets, observability, rollback, and troubleshooting. Go to Operate & deliver.
The contract in one diagram
Section titled “The contract in one diagram”AuthorityEvolutionary Modelrevision n
validate→
CompilerGeneratorversion v
materialize→
EvidenceReleaseartifacts + manifests
promote→
Observed stateRuntimedata + config + infra
The short form is: the model evolves, the software regenerates, the data migrates, releases are promoted, and production is operated. Each kind of state has one explicit authority.
What these docs distinguish
Section titled “What these docs distinguish”These docs deliberately separate three things:
- The paradigm — the normative contract an implementation must satisfy.
- The product — the modelARch experience for discovering, designing, generating, and delivering software.
- Current support — concrete model constructs, generator targets, add-ons, and infrastructure capabilities.
That separation keeps the thesis honest: a principle can be robust before every supporting mechanism is complete, while a shipped capability must never be presented as merely aspirational.