Generated code and extensions

Regenerative Software does not require pretending generated code is unreadable or inaccessible. It requires an unambiguous ownership contract.

Managed files

A managed file belongs to the generator. It may be inspected, audited, tested, and exported, but permanent edits do not belong there because the next regeneration replaces it.

Each release should record managed-file hashes. Before regeneration, compare the current tree with the prior manifest:

• no divergence → replace normally;
• divergence in a managed file → stop or require explicit resolution;
• divergence in an extension-owned path → preserve it;
• unknown file → classify by declared ownership rules.

This turns a silent overwrite into a visible event before damage occurs.

Extension surfaces

An extension is safe when:

• its directory or interface is explicitly user-owned;
• the generator never overwrites it;
• generated code depends only on a stable contract;
• compatibility is versioned and validated;
• extension failures are observable;
• security and deployment ownership are clear.

Possible extension forms include adapters, event subscribers, policy plugins, custom view registries, or separate services. They are not arbitrary patches inside generated handlers.

When to extend the model or generator

Prefer a model or generator change when the behavior:

• should be available to many products;
• affects core domain rules or permissions;
• must be reflected in tests, preview, and documentation;
• changes a supported pattern rather than a product-specific integration;
• needs to survive target changes.

Use an extension when the behavior is genuinely product-specific and fits a declared boundary.

Emergency changes

The normative operating contract does not use managed-file edits as an incident runbook. Restore service through a compatible release rollback, runtime configuration, capacity, replay, repair, restore, provider control, or fast regeneration.

If an organization nevertheless edits managed output under an exceptional break-glass process, the platform must detect the hash divergence immediately. The patch is temporary and cannot disappear silently. Before the next generation, the team must either:

• express the change in the model;
• fix the shared generator;
• move it to an extension surface; or
• declare the output forked.

Detection mitigates a broken contract; it does not make hand patches part of the paradigm.

Forking the output

Users own exported artifacts and may continue evolving them directly. A fork is explicit:

• modelARch no longer claims future regeneration will preserve manual changes;
• the generated codebase becomes the new implementation authority;
• migrations, releases, and operations continue under the user’s toolchain;
• the historical model remains useful context but not an automatically current source.

This is an anti-lock-in property, not a failure. The failure would be pretending both model and fork remain authoritative.

Operational signal

Track managed divergence and time since successful regeneration per project. Growing age is a prompt to inspect workflow health. A clean tree with an old stable release may be valid; a changed managed tree with avoided regeneration is an explicit governance breach.

See Lifecycle and Delivery channels.