Projects and Packages

Before you start creating metamodels and models, it helps to understand how Farkitect organizes your work. This guide explains projects — the top-level container for everything you do — and packages — the layered building blocks inside each project.

Projects

A project is the fundamental unit of work in Farkitect. Everything you create — metamodels, models, diagrams, catalogs — lives inside a project.

What a Project Contains

A project is a self-contained workspace that holds:

All your packages (metamodels and models)
All your diagrams, catalogs, and other views
The team members who have access, with their assigned roles

Think of a project as a shared workspace — like a team folder that everyone on the project can see and contribute to, with clear rules about who can do what.

Team Roles

Every project has members, and each member has a role that controls what they can do:

Role	What they can do
Admin	Everything — create and delete content, manage members, invite people, change project settings
Contributor	Create and edit content — elements, diagrams, metamodels — but can’t manage members or project settings
Viewer	Browse and read everything, but can’t make changes

When you create a project, you’re automatically its first admin. You can then invite others by email, choosing the role that fits their involvement.

Working with Multiple Projects

You can be a member of several projects at once, each with its own independent set of packages and team. The project switcher lets you move between them. Some common patterns:

One project per team — a single shared workspace for everyone working on the same domain
Separate projects for separate domains — e.g., one project for enterprise architecture, another for software design
A personal sandbox — a project just for experimenting and learning, with no other members

Each project is completely independent. Packages, elements, and diagrams in one project are invisible to another.

Packages — The Structure Inside a Project

Inside a project, everything is organized into packages. If you’ve read the Understanding the Four Layers guide, you know that Farkitect uses the MOF four-layer architecture (M3, M2, M1, M0). That layering shows up directly in how packages are structured.

When you open a project, the Explorer panel shows a tree of root packages, each at a specific layer. Here’s what a typical project looks like:

Explorer
├── M3 MOF Core          ← The foundation (read-only, always present)
├── M2 Common            ← Shared utilities (read-only, always present)
├── M2 ArchiMate 3.2     ← A metamodel you imported or created
└── M1 Farquind Applications      ← A model built using M2 ArchiMate 3.2

Each of these root packages serves a different purpose. Let’s walk through them.

M3 MOF Core — The Foundation

Every project starts with M3 MOF Core. This is the foundational layer that defines what metamodels can contain: Class, Property, Package, DataType, and Enumeration. It appears in the Explorer in red text.

You don’t edit M3 MOF Core — it’s read-only and managed by Farkitect itself. It’s there because every M2 metamodel needs it as a foundation. Think of it as the ground floor of the building — you build on top of it, but you don’t modify it.

M2 Common — Shared Modeling Utilities

Every project also includes M2 Common, a special M2 metamodel that provides general-purpose modeling tools. It appears in the Explorer in pale yellow text, distinguishing it from your own M2 metamodels.

M2 Common contains element types and relationship types that are useful regardless of what you’re modeling:

Element types:

Note — a sticky-note-style annotation for adding free-text commentary to a diagram
Text — a plain text label for titles, headings, or annotations
Boundary — a dashed rectangle for grouping related elements visually
Artifact — a generic document or deliverable

Relationship types:

Annotation — connects a Note to the element it annotates
Trace — a traceability link showing one element derives from or corresponds to another
Realization — indicates that one element realizes or implements another
Dependency — one element depends on another to function correctly

These tools appear in the Palette for every diagram, regardless of which metamodel the diagram uses. When you’re working on an ArchiMate diagram and want to add a sticky note, that Note comes from M2 Common. When you’re working on a UML class diagram and want to add a boundary grouping, that Boundary comes from M2 Common too.

Like M3 MOF Core, M2 Common is read-only. It’s always present and automatically available — you don’t need to import it or configure it.

M2 Metamodel Packages — Your Modeling Languages

After the system packages (M3 MOF Core and M2 Common), you’ll have one or more M2 metamodel packages. These define the modeling languages your project uses. They appear in the Explorer in blue text.

Some examples:

M2 ArchiMate 3.2 — the full ArchiMate standard for modelling systems
M2 UML Class Diagram — UML class modelling notation
M2 C4 Model — Simon Brown’s C4 architecture model
M2 Business Model Canvas — Osterwalder’s nine building blocks
A custom metamodel you built yourself

You can have as many M2 packages in a project as you need. An M1 model declares which M2 metamodel it uses via an import, and it can even import multiple metamodels to combine their types.

Some M2 packages are read-only standards that you import as-is (like ArchiMate 3.2). Others are your own creations that you can freely edit and evolve — the Creating Your First Metamodel tutorial walks you through building one.

M1 Model Packages — Your Actual Models

Finally, M1 packages are where the real modeling work happens. These are your models — the diagrams, elements, relationships, catalogs, and property values that describe whatever you’re modeling. They appear in the Explorer in the default text color (white in dark mode, black in light mode).

Each M1 package imports one or more M2 metamodels and uses their types:

M1 Farquind Applications imports M2 ArchiMate 3.2 and uses its Application Component, Business Process, and other types
M1 Farquind Digital Systems imports M2 ArchiMate 3.2 and M2 C4 Model to combine architecture viewpoints

Inside an M1 package, you’re free to create sub-packages to organize your model however you like — by business unit, by domain, by architecture layer, or any other structure that makes sense for your work.

How It All Fits Together

Here’s the complete picture of a project with two metamodels and two models:

Project: "Farquind Digital Systems"
│
├── M3 MOF Core                    ← Foundation (auto, read-only)
├── M2 Common                      ← Shared tools (auto, read-only)
│
├── M2 ArchiMate 3.2               ← Imported metamodel (read-only)
├── M2 Farquind Org Map            ← Custom metamodel you created
│
├── M1 Farquind Applications       ← Model using M2 ArchiMate 3.2
│   ├── Customer Systems/
│   ├── Manufacturing Systems/
│   ├── Application Cooperation diagram
│   └── Application Catalog catalog
│
└── M1 Farquind Organisation       ← Model using M2 Farquind Org Map
    ├── Executive & Systems diagram
    └── People Catalog catalog

The key things to notice:

M3 and M2 Common are always there — you don’t create or manage them
M2 metamodels define the vocabulary — what types of things you can model
M1 models use that vocabulary — to describe the real-world things you care about
Each package knows its layer — the M3/M2/M1 prefix in the name tells you exactly what level you’re working at

Next Steps

Now that you understand how projects and packages are structured:

Understanding the Four Layers — The MOF layer architecture explained in plain English
Packages, Imports, and Scope — A deeper dive into how imports and package roles work
Organisations, Projects, and Collaboration — How organisations, projects, and roles interact
Your First Diagram — Build something hands-on