An Ecore micro-model of architecture: elements with containment, reified relationships with tunneling, and kinds as instance data.

The tower

The micro-models form a linear tower, each model’s extension point extending the one below:

nxcore < role < iam < seal < lifecycle < decision analysis < decision binding < governance < work < architecture < threat

Architecture sits on top of work: AbstractElement extends Workable, so every element is transitively workable, governed, staged, access controlled, and engageable, and carries nxcore documentation and marker-based provenance. Architecture is the composition point of the aspect spine: everything below it is an aspect of elements, everything above it (threat, domain models) sees elements that already carry all aspects. The threat model’s Asset extends Element directly: an asset is an architecture element, and threat modeling is a lens over the architecture rather than a parallel description of it, which is what pytm and Threagile approximate with duplicated YAML.

The ordering is not arbitrary; each link is a dependency already argued elsewhere: role < iam is EngagedSubject (grants to engagement holders), iam < lifecycle is transition guards (“who may fire this transition”), lifecycle < decision is decision workflows as lifecycle instance data (Delphi rounds, approvals) with IAM-backed confidentiality, decision < binding is a binding committing an analyzed Alternative into a variation point, binding < governance is treatment and compensating-control choices as bound variation points cited by waivers, governance < work is Workable extends GovernedElement (findings trace to remediation work), work < architecture is work attachable to any architecture element, architecture < threat is assets as elements. The bar for admission to the spine: multiple floors above must have a typed need (decision passes via governance, work, and threat citations; binding passes via ADRs bound to architecture variation points, so records and model cannot silently drift). A companion rule keeps the tower honest: each floor sits at the lowest position consistent with its own dependencies, which is why binding lands directly above decision rather than directly below architecture.

Two consequences worth naming. First, a lower floor cannot use an upper aspect in its types (an IAM Realm is not itself governed); the escape hatch is a same-name upgrade class at a higher floor (governance.Realm extends iam.Realm, GovernedElement): authoring surfaces resolve the most specific class on the classpath, so adding a dependency upgrades realm { } in place, with no change to the authored source. Second, the spine is for aspects only: domain models branch off the tower at whatever floor they need rather than being forced into the line. The principal branch stack is capability < product-management < org-design, rooted just above architecture (capability providers realize elements); the agentic stack is threat < ai-governance < agent < mcp (an agent is an AISystem; tools and MCP servers stay plain Assets), making agents governed by construction; NCDA branches off decision. For estate models the placement rule has settled empirically: structural-only models branch off architecture; estate models with a security surface (Maven, ai-governance, BW5) branch off threat, because weakness containment on Asset is a typed need wherever vulnerabilities are part of the story.

Competitive landscape

Structurizr / C4. The closest in spirit: model-based, diagrams generated, DSL-authored. But the C4 metamodel is fixed and the workspace is the silo; there is no aspect composition, no federation across workspaces beyond links. Here C4 is one catalog plus a thin extension over a smaller metamodel.

ArchiMate / Archi. A rich standardized metamodel, and that is the problem: ~60 element types that practitioners subset anyway. Kinds-as-data inverts it: the notation is loadable vocabulary, the metamodel stays at five classes.

EA platforms (LeanIX, Ardoq, Bizzdesign). Repository-backed, discovery-fed, proprietary. Same critique as GRC and threat-modeling platforms: the architecture lives in the platform, and the crosswalk to risk, threats, and access is manual or absent. The micro-model tower makes those crosswalks inheritance and references.

Backstage catalog. The most instructive comparison: a tiny entity model (kind, spec, relations) as data in git, wildly adopted precisely because it is small and federated. This model is that shape, with a typed metamodel, reified relationships, tunneling, and generated documentation instead of YAML conventions.

Applications

The threat modeling course exercise has its substrate: model the AI dashboard once as architecture, then threat-model it (Asset extends Element), govern it, and access-control it against the same elements. Cross-system generated views (a model of ElementReferences spanning published models) are the wedge play: the consumer sees a coherent view, the model stays invisible. Micro-wikis get their site map: element containment is the space hierarchy. And the Draw.io surface plus Groovy prototypes make the authoring story the old model promised, minus the metamodel toll.

Model overview