Skip to content
Farkitect
🤷

Forgive us! These docs are a work in progress. Some pages may be incomplete or describe features that aren't quite finished yet. Farkitect is in early development and we don't recommend using it for real work just yet. Feel free to explore — just be aware that things are still being built.

How to use the M2 lifecycle

As your metamodel evolves, Farkitect provides lifecycle features to help manage the impact of changes on existing M1 models.

Track usage

Section titled “Track usage”

To see which M1 elements use a particular M2 type:

  1. Select the M2 element type or relationship type
  2. In the Properties panel or Context panel, look for usage information — how many M1 instances are classified by this type

This helps you understand the impact of changes before making them.

Deletion guards

Section titled “Deletion guards”

Farkitect prevents you from deleting M2 types that are in use:

  • If you try to delete an M2 element type that has M1 instances, the deletion is blocked with a message showing how many instances exist
  • You must either delete or reclassify all M1 instances before the M2 type can be removed

This prevents accidental orphaning of model elements.

Renaming M2 types

Section titled “Renaming M2 types”

Renaming an M2 element type is safe — M1 instances reference the M2 type by ID, not by name. The rename propagates immediately:

  • The Palette shows the new name
  • M1 elements show the updated classifier name in the Properties panel
  • Diagrams re-render with the updated stereotype label
  • Exports use the new name

Modifying M2 properties

Section titled “Modifying M2 properties”

You can add, remove, or modify properties on an M2 type at any time:

  • Adding a property — all existing M1 instances gain the new field (initially empty or with the default value)
  • Removing a property — existing property values on M1 instances are orphaned (no longer displayed, but data is retained)
  • Changing a property type — existing values may become invalid; the integrity checker flags type mismatches

Modifying constraints

Section titled “Modifying constraints”

Changing relationship constraints affects future relationship creation but does not retroactively invalidate existing relationships. The integrity checker can detect M1 relationships that violate updated constraints.

Best practices

Section titled “Best practices”
  • Make M2 changes during quiet periods when collaborators aren’t actively modelling
  • Use the integrity checker after M2 changes to identify any M1 inconsistencies
  • Consider marking mature M2 metamodels as read-only to prevent accidental modification
  • Export your M2 as a .farki backup before making significant structural changes