Skip to content

The metamodel

The metamodel is the rulebook the model of record is built on: which entity types and relationships exist, what scoring dimensions each type carries, and which viewpoints are available. eavantage ships a default rulebook, but it isn’t fixed — a firm can reshape it to its own EA method.

  • Deployment-wide, by a Platform Administrator, at Admin → Metamodel (alongside the other platform setup in Platform setup). This is the firm’s standing rulebook, applied to every engagement.
  • Per engagement, by an Engagement Lead, as an overlay on top of the deployment-wide rulebook — for the parts of modelling that need something the firm-wide setup doesn’t have. An overlay can re-enable something the firm disabled, or add a type just for that engagement.

Both edit the same underlying configuration and validate against the shipped ontology, so an overlay can’t put an engagement into an inconsistent state.

  • Disable or narrow a built-in entity type, relationship, or scoring dimension you don’t use — including which types a relationship is allowed to connect.
  • Rename types, relationships, and viewpoints into your firm’s own language, and re-word a built-in type’s description to match your method.
  • Define your own entity types and relationships — a defence client’s “Mission Thread,” an insurer’s “Regulatory Obligation” — with plain attributes: text, number, boolean, or enum.

A custom type is not a second-class citizen in the model:

  • It becomes a real, first-class label in the model of record, written through the same single writer as every shipped type.
  • It carries the same tenant isolation and audit trail as a shipped type.
  • Its candidates never auto-commit, regardless of confidence — the AI has no priors for a type it’s never seen, so even a strong, well-sourced extraction floors at batch review; a weaker one goes to individual review, same as any core type. See Reviewing AI candidates.

Renaming doesn’t change what’s extracted

Section titled “Renaming doesn’t change what’s extracted”

Renaming a type or relationship, or re-wording its description, is display-only. Underneath, the AI extractor and the graph writer always use the built-in names — so relabelling “Capability” as “Business Function” for your firm changes what your team sees, never what the AI does or how the model validates.

On top of any rulebook — shipped or reshaped — you can build a viewpoint: a matrix, catalog, decomposition tree, network map, flow, or timeline, bound to any slice of the model, including your own types. A viewpoint renders read-only from the current, approved model and updates as the model does. A decomposition-tree view can roll a number up an “is part of” hierarchy (sum, average, max, or min) as you read it.

Reshaping the metamodel never touches the guarantees the rest of eavantage is built on:

  • The single-writer rule — exactly one component writes the model of record — is not configurable.
  • Tenant isolation and the human-approval gate are not configurable.
  • A custom type can only add a label. It can never remove a guarantee the shipped ontology already gives you.

Three limits worth knowing before you lean on a custom type:

  • The LeanIX, Ardoq, and Sparx exporters map from a fixed type dictionary and silently skip custom types — they just don’t appear in that export. Only the ArchiMate export carries them.
  • Gap analysis and recommendations run against the core types (Capability, Application, Business Process, and so on) and skip custom types — a custom type won’t generate a gap or show up in a recommendation’s rationale.
  • Wiring a custom type into a specific heat map, deliverable, or export renderer beyond this is a scoped request for that engagement, not something the editor itself configures.

A metamodel change is configuration, not code — it survives every update the same way your other admin settings do. Each engagement is pinned to a snapshot of the rulebook at the moment it’s created, so a later firm-wide change never shifts a project that’s already underway. Adopting a change on an existing engagement is an explicit choice (“re-pin”), not something that happens to you.


A governance-first tool is only as useful as the method it lets you run. If eavantage’s shipped entity types and relationships were the only ones available, a firm with its own EA method — or a client with domain-specific concepts a generic ontology doesn’t have a name for — would be fighting the tool. The metamodel is how that tension goes away without weakening what makes the model defensible: the write, isolation, and approval guarantees apply to a custom type exactly as they do to a shipped one.

This is covered for a prospect audience on Capabilities.