Skip to main content

Meta model

The Caplo meta model is the set of reusable element types, relation types, and configurable properties available in your workspace.

You do not need to enable everything on day one. Caplo works best when you start with a small set of types that support the questions you actually want to answer.

Enabled element types​

Caplo entity types are based on ArchiMate, with a few practical Caplo-specific additions such as vendors.

Use Settings > Entity metamodel to choose which element types are available in the diagram toolbar and related creation flows, and to configure that type's properties. This keeps modeling focused and avoids showing types your team does not use.

Typical starting sets include:

  • Application landscape: Application, Application service, Interface, Data object
  • Business architecture: Capability, Process, Business actor, Business service
  • Transformation planning: Goal, Outcome, Work package
  • Practical extensions: Vendor when supplier context matters

If you need a visual mapping between Caplo and ArchiMate, see Caplo vs. ArchiMate.

Entity types​

Every entity in the Repository has one type. That type controls:

  • How the entity is labeled in the toolbar and Repository
  • Which properties can be shown or edited
  • Which relations make sense during modeling and analysis

Choose the type that best matches the real-world thing you want to reuse. If your team is unsure between two close types, pick the one that helps reporting and diagram reuse most clearly.

Relation types​

Common reusable relation types in Caplo include:

  • Association for a general connection
  • Child of for composition (the part points at the whole)
  • Aggregated by for aggregation (the part points at the whole)
  • Assigned to for assignment (the source points at what it is assigned to)
  • Realizes for "this implements or supports that"
  • Specializes for a more specific concept pointing at the general one
  • Accessed by for data or object access
  • Serves for one element providing a service to another
  • Influences for a motivation element affecting another
  • Triggers for process or event flow
  • Flows for movement of data, information, or work

Caplo can infer some of these relations for you while modeling on a diagram. When the connection is only explanatory, keep it diagram-only instead of turning it into reusable repository structure.

Hierarchy in Caplo​

Caplo uses Child of as its explicit reusable hierarchy relation, but the directional model is broader than that.

Most reusable relation types in Caplo follow one consistent rule: the stored direction goes from the lower, more detailed, or supporting side to the higher, more abstract, or consuming side.

Examples:

  • Child -> Parent for Child of, and part -> whole for Aggregated by
  • Application -> Capability for Realizes
  • Data object -> Application for Accessed by
  • Actor -> Role for Assigned to
  • Source application -> Target application for Flows
  • Triggering process -> Triggered process for Triggers

This directional convention matters across the product:

  • The Repository stores the canonical relation direction this way.
  • Same-type nesting in diagrams creates or reuses Child of.
  • Nesting two different types creates a repository relation only for Child of, Aggregated by, or Accessed by. Other connections stay on the diagram.
  • Graph exploration and reports traverse relations directionally, so top-down and bottom-up produce different results.

If you are only trying to group shapes visually, use a diagram-only grouping approach rather than implying reusable structure.

Association is the least-specific relation type. Use it for a general connection, not when the directional meaning is important.

Entity and relation properties​

Caplo calls configurable metadata properties properties in the product UI.

Use Settings > Entity metamodel and Settings > Relation metamodel to choose which types are available and to configure their metadata.

  • Entity metamodel covers entity types and entity properties.
  • Relation metamodel covers relation types and relation properties. A relation type that is already in use cannot be disabled. Disabled entity and relation types cannot be created in the app, MCP, or REST API. Existing records remain readable.

Good properties are the properties that help your team filter, compare, color, group, or report on the model. Examples include owner, lifecycle, criticality, cost, risk, interface metadata, or review status.

Every entity type also has built-in Phase in and Phase out fields. These describe when an item becomes active and when it is planned to retire.

  • Leave Phase in empty when the item is already active.
  • Leave Phase out empty when there is no planned retirement.
  • Set an exact day when you know the date.
  • Set a year, quarter, or month when you only know the period. The item is treated as active for the whole period. Diagram and landscape As-is / to-be coloring use that same window: not-yet-live items are TO-BE - Arriving, live items that remain are AS-IS, and planned retirements are TO-BE Leaving. The shape or card eases across the window instead of switching on one day.

Custom entity and relation properties can also use Date or range for the same exact-day or year / quarter / month values. An empty custom Date or range is just unset.

Properties vs. relations

Use a property when you want metadata on one item. Use a relation when you need to explain how two items connect.

Keep it small at first​

If your workspace is new, start with a narrow meta model. It is better to have a small, well-maintained set of element types and properties than a theoretically complete model that nobody uses consistently.