Lifecycle

The regenerative lifecycle is a controlled sequence of state transitions. A successful build cannot skip migration planning, readiness, or promotion evidence.

End-to-end sequence

1. Express and approve a product change
2. Create an immutable model revision
3. Validate structural and semantic invariants
4. Compile with a versioned deterministic generator
5. Produce artifacts, manifests, migrations, and test evidence
6. Approve a release plan
7. Build an isolated candidate
8. Apply compatible data evolution exactly once
9. Run health, readiness, and smoke verification
10. Switch traffic atomically
11. Observe the new release
12. Mark stable, roll traffic back, or supersede with a forward fix

Release states

State	Entry condition	Safe exit
Planned	Revision and target resolved	Approve or block on missing intent
Building	Approved plan starts materialization	Candidate artifacts or failed build
Migrating	Evolution plan approved	Verified schema state or failed release
Verifying	Candidate is isolated and ready to probe	Candidate ready or failed release
Active	Traffic switched to candidate	Observing
Observing	New release serves traffic under watch	Stable or rolled back
Stable	Observation window passed	Superseded by a later release
Failed	A gated step failed	Explicit idempotent retry or new plan

State must be durable. Restarting the orchestrator cannot erase whether a migration was applied or whether a candidate received traffic.

Idempotency

Every step needs a stable operation key. Retrying after a timeout must inspect recorded and observed state before acting again.

Examples:

• an artifact upload with the same checksum is reused;
• an applied migration checksum is verified rather than rerun blindly;
• candidate creation reconciles to the desired release identity;
• traffic promotion records the previous active release;
• cleanup can resume independently.

Time since regeneration

“Time since last regenerate” is a useful operating signal, not proof of conceptual failure. Track it with:

• revision age;
• ungenerated model changes;
• candidate lead time;
• divergence status of managed outputs;
• outstanding migrations;
• unpromoted fixes.

A team that routinely edits managed output and avoids regeneration has abandoned the contract in practice. The platform should make that visible before the next build—not discover it six weeks later during overwrite.

Failure safety

A failure before traffic promotion leaves the active release untouched. A failure after promotion invokes the compatibility-aware rollback or forward-fix policy. Partial candidates and unverified migrations never become active merely because a process crashed.

Evolution cadence

Regeneration should be cheap enough to remain routine. Small model revisions reduce migration size, narrow review, and make causal analysis easier. However, cadence cannot substitute for correctness: a fast unsafe migration is still unsafe.

Continue with Data and migrations and Releases and rollback.