Mental model

The most useful mental model is not “AI writes an application.” It is a product model is compiled into several coordinated projections.

One hub, several projections

The Evolutionary Model is the hub. Authoring surfaces write to it; consumers read from it.

Conversation ─┐
Canvas ───────┼──► Evolutionary Model ──► validation
Templates ────┘              │           ├──► executable specifications
                             │           ├──► generated application
                             │           ├──► preview
                             └───────────► persistence and revision history

The canvas is a view of the model, not a parallel source. The AI proposes model changes, not direct DOM or code changes. Generation consumes the same model that validation and preview understand.

Compilation, not round-trip editing

Traditional model-driven tools often fail when the generated code is edited and the model is later regenerated. Both sides claim authority, so the team must merge them.

modelARch uses a one-way contract:

1. author intent in the model;
2. validate it;
3. compile it with a known generator version;
4. replace managed output on the next generation.

There is no promise to reverse-engineer arbitrary code back into equivalent product intent.

One source for each kind of truth

“The model is authoritative” does not mean it stores everything:

Question	Authority
What should the product do?	Evolutionary Model
How does supported intent become code?	Generator
Which artifact was promoted?	Release record
What rows exist now?	Live database
Which secret or endpoint is active?	Configuration control plane
Which release receives traffic?	Infrastructure/orchestrator
What is happening now?	Observability

Robustness comes from non-overlapping authority and explicit transitions—not from collapsing all state into one document.

Five different operations

• Regenerate: model + generator → application artifacts.
• Migrate: current schema/data + evolution plan → compatible persistent state.
• Deploy: approved artifact + infrastructure → isolated candidate.
• Promote: verified candidate → release receiving traffic.
• Reconcile: desired operational state + observed state → repair or visible divergence.

These verbs are intentionally different. Regenerating does not recreate customer rows. A traffic rollback does not automatically undo a destructive schema change. Changing an API key does not require a product revision.

Determinism is a constraint, not a quality claim

A deterministic generator should produce semantically equivalent output for the same versioned inputs. That removes accidental variation and makes a generator defect reproducible.

It does not guarantee that:

• the model is correct;
• the generator supports every possible product;
• a migration is safe at the current data volume;
• an external service will remain available.

Those concerns are handled through validation, declared capability boundaries, migration planning, and operations.

The test

When deciding where a change belongs, ask: which authority owns the fact that changed?

• Desired behavior changed → revise the model.
• Model is correct but output is wrong → fix the generator.
• Endpoint or credential changed → update runtime configuration.
• Workload grew → operate infrastructure or improve the generated strategy.
• Stored values are wrong → repair, replay, quarantine, or restore data.

Continue with Authority boundaries for the complete contract.