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.
Where it’s configured
Section titled “Where it’s configured”- 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.
What you can change
Section titled “What you can change”- 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.
What a custom type gets
Section titled “What a custom type gets”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.
Building your own views
Section titled “Building your own views”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.
What doesn’t move
Section titled “What doesn’t move”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.
What this doesn’t reach
Section titled “What this doesn’t reach”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.
Safe across updates
Section titled “Safe across updates”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.
Why it matters
Section titled “Why it matters”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.