How to generate a metamodel with FarkiBot
Generate M2 asks FarkiBot to invent a modelling language: the element types, relationship types, properties, notation and constraints that a domain needs. The result arrives as a staged package you review before it touches your project.
This is the deepest thing FarkiBot does, and the one where model choice matters most. A metamodel is built once and everything you model later is built on it, so a flaw echoes a long way.
Before you start, set up FarkiBot. You need contributor access or above.
Generate a metamodel
Section titled “Generate a metamodel”- Open View > FarkiBot and switch the task dropdown to Generate M2
- Optionally attach a standard or specification (see below)
- Describe the modelling language you want
- Choose a starred model in the LLM picker
- Press Enter
Write the brief
Section titled “Write the brief”Describe the language you wish existed. FarkiBot designs the element types, relationships, notation and constraints from it.
A good brief says what the language is for:
An M2 for C4 architecture diagrams — Person, Software System, Container and Component, with relationships that respect the C4 nesting rules. Containers belong to a Software System; Components belong to a Container.
A weak brief just names a subject:
C4
Say what you want it to enforce, too — constraints are the part of a metamodel that does the work later:
A supplier risk metamodel. Suppliers provide Services, Services support Business Processes, and a Supplier can’t directly support a Business Process — it has to go through a Service.
Attach the standard
Section titled “Attach the standard”If you’re implementing a published notation, attach it. FarkiBot will stick to it rather than reconstructing it from memory, which is the difference between a metamodel that matches the standard and one that merely resembles it.
Accepted attachments: .md, .txt, .pdf, .docx, .farki. PDFs go to the model natively — no conversion step. Word documents are read straight from the file with their headings and lists intact, because the structure of a specification is part of what FarkiBot needs to read.
Attaching an existing .farki metamodel is a good way to say “like this one, but for a different domain.”
What happens while it runs
Section titled “What happens while it runs”- Reasoning models stream their thinking first, then the raw file streams in
- FarkiBot validates the result against the real importer — the same code path that would import a file you wrote by hand
- Problems are fed back for repair, up to three attempts
- The output token limit in effect is shown next to the LLM picker, and FarkiBot raises it automatically if the model runs out of room
Runs live in your browser tab. Reloading or closing the tab ends them.
Review before importing
Section titled “Review before importing”Nothing touches your project until you say so. The staged card shows element counts, warnings, and cost.
- Review opens a Contents tree of the package — every element type, relationship type, property and constraint, with relationships showing the names they connect rather than internal ids. A Source tab shows the raw
.farkifile. Search the tree to find anything in it. - Save .farki… downloads the file
- Import brings it into your project
- Discard throws it away
Every generated package carries a provenance note naming the model that produced it and the date. Name conflicts are detected at import.
Staged packages survive reloads, up to 10 per project — the oldest is evicted after that.
What to check in the review
Section titled “What to check in the review”A metamodel is worth reading properly before you import it, because everything you build on it inherits its decisions:
| Check | Why |
|---|---|
| The element types are the right ones | Too many is worse than too few — every extra type is a decision every modeller has to make forever. |
| Relationship constraints exist and are right | A metamodel with no constraints doesn’t stop anything. One with wrong constraints stops the wrong things. |
| Properties are on the right types | A property in the wrong place is tedious to move once instances exist. |
| The notation is distinguishable | Six element types in the same colour and shape is a diagram nobody can read. |
You can edit any of this after importing — see How to create an element type and How to configure notation.
If it fails
Section titled “If it fails”If a run fails validation after all attempts, the failure card explains why in plain language, offers the raw output for download, and Try again resubmits the same brief — with the same or a different LLM.
M2 generation is harder than M1 generation, and weaker models fail it far more often. An M2 has to invent the whole structure and its notation, including inline SVG icons inside JSON strings where a single mis-escape invalidates the entire file. If a free model fails three attempts here, that’s expected, not a bug. See How to choose an LLM.
Metamodels can’t be modified by FarkiBot
Section titled “Metamodels can’t be modified by FarkiBot”Once imported, a metamodel is edited directly, not regenerated. Modify M1 deliberately excludes M2 packages — replacing one would break every model built on it. See How FarkiBot Works for the reasoning.
Related
Section titled “Related”- How to generate a model
- How to choose an LLM
- Creating Your First Metamodel — building one by hand
- How to use the M2 lifecycle