Models

Overview video (~4 min)

The portfolio

The tower is not a product suite. It is a set of small micro-models, each published on its own, each depending only on the floors below it, each generating its own documentation site. What makes it a portfolio rather than a pile is that the floors compose: a concern defined once at the bottom - identity, documentation, provenance, time - is inherited by everything above it, and a model that takes its position in the tower stops defining the concerns a lower floor already provides. The tower gets taller and the models get smaller.

Taken together they let you model an organization and its solutions end to end: from a button in a UI down to a field in a mainframe copybook, carrying ownership, access control, lifecycle stage, decision history, risk, control, evidence, cost, and work along the whole path. The same graph answers “which teams depend on this system of record”, “who approved this alternative and on what analysis”, “which controls cover this requirement”, “what has this migration cost so far and what remains”, and “what breaks if this vendor library has a CVE” - because those are not four tools’ worth of data reconciled by export, they are four aspects of the same elements.

Time is a dimension, not a column

Every element is positioned in time, and time may be relative or partially known. A person who will be hired in a year is a modelable person. Work that starts when a vendor GAs a product and the security review clears is modelable work, with the dependency stated rather than implied by a date somebody guessed. An organizational unit that exists for two quarters, a control that applies only after a framework version takes effect, a capability provider valid until its contract ends - all of these are periods with history, not rows that get overwritten and lose what they used to say.

Plans, current state, and history are the same model read at different points on the time axis.

Who it is for

Anyone who has to grasp complex information quickly and communicate it accurately. Consultants first: an engagement is mostly a race to understand an unfamiliar estate, and the deliverable is usually a deck that stops being true the week after it ships. A model is a deliverable that keeps working - it can be handed over, extended, queried, and regenerated by the client long after the engagement ends. The same argument applies inside an organization to architects, risk and compliance functions, product managers, and anyone who inherits a system nobody has documented since the last reorg.

Templates matter here. A reference architecture, a standard org shape, a control set, a persona catalog - these are models, and a new engagement or a new business unit starts by instantiating one rather than by opening an empty page.

Pick your floor

The tower is meant to be entered in the middle.

• Ignore what is above. If you need requirements traceability, take the floors up to requirements and stop. Nothing above them has to exist for the ones below to work.
• Ignore what is below. The lower floors are the water heater in the basement: load-bearing, and not something you are supposed to think about until it breaks. You do not need to understand markers and evaluators to write down who owns a system.
• Recombine. Floors are Maven artifacts under version control. Fork one, and a floor can sit on a different version of a lower floor without a single change to its own code. Different organizations can run different assemblies of the same tower and still exchange model fragments by reference.

Adoption is one micro-model at a time, which is only realistic because micro-models are cheap to author - the Xcore archetype plus AI assistance for the first cut - and cheap to publish - the Nasdanika CLI plus GitHub Pages.

Inheritance, one floor down

Everything above is inheritance between metamodel classes: an asset extends an architecture element, a section acquires ownership, a floor stops defining what the floor below already provides. The same idea applies one level down, between objects - and that is what turns a template from a starting point into a living relationship.

The mechanism is that references are named slots. A single-valued reference is a slot with a name; a many-valued reference with eKeys is a set of slots addressed by key. Once every feature of an object is addressable by name, an object can declare a base and then, recursively, do three things to what it inherits: add, replace, and suppress.

Add and replace are ordinary object-oriented inheritance. Suppress is the one Java has no counterpart for - a subclass cannot un-inherit a member - and containment is what makes it necessary: a derived object has to be able to say that an inherited element is simply not there, which inside a container means deletion. Docker layers work exactly this way. A layer adds files, replaces files, and whites out files from the layer beneath; the result flattens into one image; and every file still knows which layer put it there. That last part is the point - the flattened model is what you read, and the layer that contributed each value is what you audit.

Authoring. The Groovy DSL has the first step already: copy('<uri>') resolves an element, deep-copies its containment subtree, rewires references inside the subtree to the copies, leaves references out of it pointing where they pointed, and hands the result to a closure that adjusts it.

architecture {
    name 'Payments'

    copy('payments.drawio#//@nodes.0') {
        description 'Fronts the card networks'
        owner 'platform-team'
    }
}

That is a prototype rather than inheritance: a one-time snapshot, where later edits to the base never reach the copy. Inheritance keeps the link live and resolves it on load, so the base can keep moving. The named-slot approach carries to other authoring surfaces without inventing a new mechanism - in Markdown, attributes name the prototypes or bases and the merge strategy, per element or per section, so adopt-and-adjust works where people are already writing.

Why it matters. An org-wide policy is inherited - adopted - by a business unit and adjusted to it: two controls tightened, one suppressed under a waiver, an owner replaced. The unit’s model holds the delta and nothing else, so “how do we differ from the standard” is a query rather than an archaeology project across two documents that were forked eighteen months ago. When the standard changes, everything that inherits it changes with it, and the overrides are precisely the list that has to be re-reviewed. The same applies to a reference architecture specialized per workload, a global SDLC narrowed for a regulated team, and a UI where a role-specific screen replaces one field and suppresses another.

Model inheritance is designed rather than finished; it gets implemented on demand, as models start to need it. Metamodel inheritance made the models small. Model inheritance makes the model content small.

Why AI is load-bearing

Two reasons, and they point in opposite directions.

AI reads the structure. A model of an enterprise is larger than any one person can hold, which is exactly the condition under which organizations give up and declare that tribal knowledge rules. An assistant can traverse the whole graph, and because the graph is typed and every element carries provenance, its answers are checkable: they cite elements, and elements cite their sources and commits. Reasoning over a typed model is a different activity from summarizing a wiki.

AI writes the structure. The reason models rot is that updating them is somebody’s least favorite chore. An assistant reads the meeting notes, drafts the model updates, asks the human to confirm, and applies them. What lands is a commit with feature-level change records and telemetry stored beside the model, so a change is attributable at the granularity of the attribute that changed, not the file that changed.

And a commit is a message. It can trigger action: classify a change as material and open a governance review; detect that a new flow crosses a trust boundary and reopen the threat model; notice that a control’s evidence went stale and raise work against its owner. Governance stops being a quarterly interview and becomes a reaction to a change that already carries its own explanation.

Landscape

Each model states its own positioning on its own site - the requirements model against DOORS and Jama, the threat model against IriusRisk and Threat Dragon, the architecture model against ArchiMate and Backstage, and so on. At the portfolio level the comparison is a different one, because the alternative to the tower is not a product. It is a stack of them: an EA repository, a GRC platform, a requirements tool, a developer portal, a data catalog, a threat modeling tool, an org charting tool, and a drawing tool - each with its own identity model, its own idea of ownership, its own lifecycle vocabulary, joined by exports, CSV round-trips, and somebody whose job is reconciliation.

The tower’s claim is narrower and stronger than “does everything”: one typed vocabulary defined once and inherited everywhere, stored in Git so versioning, branching, and federated ownership come from tooling teams already run, with documentation as a generated artifact rather than a parallel deliverable, under an open license so a model is not hostage to a subscription.

Its limits are worth stating too. This is a modeling substrate, not a data-entry portal for hundreds of casual users; much of the value comes from loading and snapshotting what already exists in Jira, GitLab, spreadsheets, and diagrams rather than from asking people to type it in again. And the floors below are Ecore, EMF, and Java - twenty-year-old load-bearing technology, which is the point, but it is a technology choice and not a neutral one.

Tower floors

• NxCore - the base floor: model elements that are named, documented, identifiable, referenceable, positioned in time, and aware of where they came from. Documentation is structure - sections and content - not a text blob. Provenance is carried by nested markers, with Git markers adding commit, branch, and origins. The time dimension covers points and periods, including relative and partially known time. Evaluators supply computed values from expressions and scripts. Everything above inherits identity, documentation, provenance, and time without redefining them.
• Role - ownership and responsibility as Undergoer, Role, and Actor: who is responsible for what, to whom, and when. Role also defines its own Section and Content extending both NxCore and Role, so documentation itself acquires ownership - every section of a document can answer “whose is this”.
• IAM - realms, principals, groups, roles, actions, and authorization statements attachable to any model element, for people and agents alike. Both resource-side entries (XACML style) and subject-side permissions (Shiro style) are supported, along with engagement-based rules such as “the owner may edit”. Authentication, credentials, and federation are deliberately out of scope, left to the enforcement layer. Uses: identity-scoped generation - one source, many audiences, many formats - Shiro-backed enforcement in web UIs, and tiered element-level visibility.
• Seal - signing and encryption for models: non-repudiation for judgments, approvals, and sojourns, and confidentiality so a model can be distributed widely and still protected element by element.
• Lifecycle - stages and transitions for anything that has a status: Lifecycle catalogs, hierarchical Stages, guarded Transitions, and Sojourn - a dated, attributable, signable record of time spent in a stage. Stages are instance data rather than enums or process tokens, so an element can sit in several lifecycles at once and history is first class. Unlike Jira workflow schemes or a BPM engine, the lifecycle travels with the model. Uses: capability maturity, editorial workflow, compliance audit trails, segregation of duties.
• Accounting - double-entry accounting as a spine aspect: hierarchical accounts holding multiple commodities - dollars, hours, LLM tokens, story points, anything countable - transactions with correspondent legs, and assertions as first-class entries: dated statements of fact with provenance, so reconciliation can show exactly where computed amounts diverge from asserted reality. Everything above this floor is accountable: time spent on work, tokens burned by an agent, cloud cost of an architecture element, and the cost of a control or a decision are entries in one vocabulary, rolling up along containment. Amounts may be evaluator-supplied with recorded evaluation history - facts freeze, estimates re-evaluate - which is what makes priced templates and calibrated migration estimates work. Telemetry loads as entries: monotonic counters are transactions, gauges are assertions. Unlike ERP ledgers or FinOps tools, cost is not a separate system reconciled by export; it is an aspect of the elements that incur it. Also stands alone as a personal and household finance model - the floors below are small, and the floors above are optional.
• Decisions
  • Analysis - multiple-criteria decision analysis as a record, not a spreadsheet: criteria hierarchies, alternatives, expert panels, judgments including pairwise comparisons, and computed results, with aggregation method chosen per node. Judgments are signed and dated with override trails rather than overwritten cells, criteria catalogs are versioned reusable artifacts, and Delphi-style confidentiality comes from IAM. Positioned as a complement to the arithmetic rather than a replacement - Excel for the math, the model for the record - and against vendor silos such as Expert Choice and Decision Lens.
  • Binding - which alternative was committed into which variation point, by whom, on what analysis, and depending on which other decisions. Architecture decision records that cannot silently drift from the architecture they decide, because both are elements in the same graph.
• Governance - frameworks, policies, controls, control applications, risks, evidence, assessments, and waivers, following industry practice: ISO management systems, NIST, OSCAL patterns. Crosswalks are references, so one control answers many requirements across frameworks, and compliance status is structure rather than a cell colored green. Governed is an aspect: anything in the tower can carry a governance overlay. Audit packs and compliance views are generated, with export to OSCAL and CycloneDX.
• Work - work items attachable to anything through Workable: Work, WorkType, Dependency, and TemporalConstraint, with containment establishing ownership and impacts recording effects on elements elsewhere in the graph. Work loads from Excel, Draw.io, and PlantUML, treating those artifacts as authoritative sources rather than as exports from a tracker, and inherits staging, ownership, and access control from the floors below. A governance finding traces to its remediation work; a work item traces to everything it will disturb.
• Requirements - normative statements at element level: Requirement, Satisfier, a reified and queryable Satisfaction claim, Verification with method, verdict, and evidence, and requirement kinds for functional, quality attribute, constraint, and business rule. Requirements-as-code between the heavyweight tools (DOORS, Jama, Polarion) and the plain-text ones (Doorstop, StrictDoc): requirements can be worked on, satisfied by architecture elements, approved through a lifecycle, and federated across organizational boundaries by reference.
• Architecture - elements with containment, reified directed relationships, and ElementReference for federation. Kinds are instance data, so C4, ArchiMate, and TOGAF vocabularies load as catalogs instead of being burned into the metamodel. Smaller and more federated than ArchiMate’s sixty-odd element types, and typed metamodel composition rather than YAML conventions as in Backstage. Every architecture element is transitively workable, governed, staged, access controlled, owned, and documented with provenance. Uses: threat modeling in place, cross-system views spanning published models, wiki site maps from the containment hierarchy.
• Threat - assets, flows, trust boundaries, threats with attack trees, threat actors, and weaknesses, organized around Shostack’s four questions and joined to governance through controls, risks, and waivers. Asset extends the architecture element, so there is no parallel description to keep in sync - the security lens is a view of the architecture, not a copy of it. Methodology is data: STRIDE, MITRE ATT&CK, ATLAS, and the OWASP lists load as queryable catalogs. Unlike diagram-first tools (Microsoft TMT, OWASP Threat Dragon) or platforms that silo threat data (IriusRisk, ThreatModeler), an architecture change can surface a new threat, and exports - TMBOM, Threat Dragon JSON - keep the data portable.
• C4 - the C4 vocabulary - person, software system, container, component.

Rooftop and balconies

Branches off the tower at the floor they need.

• Telemetry - OpenTelemetry concepts as Ecore: traces, spans, metrics, and logs. Telemetry as code, stored beside the model, is what makes feature-level change recording work: a commit can say which attribute of which element changed, in which execution, at whose request. Telemetry sits on the work floor - counters load as transactions, gauges as assertions, and spans are work done by actors (e.g. AI agents) - so a telemetry dashboard and an account dashboard are the same componentry over the same entries.
• System of Records (SOR) - the physical data estate: systems, datasets, record layouts, and fields, with COBOL copybooks and data items and SQL tables and columns as concrete specializations, including the structural facts a spreadsheet cannot hold such as REDEFINES and OCCURS DEPENDING ON. The core contribution is VocabularyMapping - many-to-many and context-qualified - which records how one business term such as Transaction.amount is actually realized in deposits, cards, and loans. Governance, lifecycle, ownership, and work come from the floors below. Uses: data stewardship, regulatory work such as GDPR and BCBS 239, migration planning, and grounding for AI agents. Existing spreadsheets, Confluence pages, and extraction tools are treated as sources, not rivals; the contrast is with data catalogs (Collibra, Alation) and ER tools that leave field-level business semantics undeclared.
• AI
  • AI Governance - AI systems as inventory entries inside the governance framework: risk taxonomies, impact assessments, human oversight modes, model cards, incidents, and telemetry-backed evidence, mapped across ISO/IEC 42001, NIST AI RMF, and the EU AI Act. One control, many requirements - the same crosswalk mechanics as the governance floor, applied to AI, and composable with the agent and threat models rather than sitting in a separate GRC or MLOps silo.
  • Agent - framework-neutral declarative specification of agentic systems: agents as personas bound to language models, plus tasks, tools, skills, and examples. Because AISystem is upstream, agents are governed by construction - risk tier, evaluations, oversight, and threat surface exist before the first call executes. Subject matter experts author and review behavior without writing code; models generate browsable documentation, diff semantically in Git, and either generate code for a target framework or execute directly on the Java runtime. Complements interchange formats such as Open Agent Spec by being a typed metamodel rather than a wire format.
  • MCP - Model Context Protocol servers as organizational assets rather than endpoints: federated catalogs, server versions with capabilities, distributions - packages and remotes - and tools, resources, templates, and prompts, with optional bindings for executable behavior. The specification says how to connect and the registry says what exists; this model answers what we have, who owns it, whether it is safe, and whether we can prove it.
• Capability - capabilities, the providers that supply them, and the evidence behind the claim. The root of the pull stack: a capability is something a concern reaches for, not something a vendor pushes.
• Product management - persona to concern to capability to provider, made machine-readable and federated. Goals, needs, pain points, evidence, ownership, and temporal validity are typed, published as Maven artifacts, and composed across teams without a central administrator. Pull rather than push: a capability is found because it addresses a stated concern with documented evidence and an accountable owner, not because it appeared in a slide deck. A methodology-neutral substrate rather than a competitor to OKR or V2MOM, and distributed where roadmap platforms and catalogs are centralized. Uses: portfolio deduplication, federated goal alignment, AI-assisted reasoning over intent.
• Org design - units, roles, people, capabilities, decision rights, and coordination mechanisms as typed, time-aware elements rather than boxes on a chart. A person extends a persona and provides capabilities with evidence, which is what gives personas organizational coordinates. The unit of analysis is a period with history, not a row to update, so reorganizations, scenarios, and cost projections anchored to organizational events are all expressible. Against Workday or OrgVue: typed decision rights, capability overlap detection, fit rules, and federation by URI reference instead of hand-maintained copies.
• **Family - a family as an organization: members who provide, consume, develop, and transfer capabilities across generations, with kinship as typed relationships and GEDCOM as the interoperability format.
• UI - a micro-model of functional user interfaces: structure, layout, data binding, and event handling, with presentation deliberately left downstream. ValueBinding (one-way, two-way, one-time), EventBinding, Iterator, Conditional, and DataContext say what is bound; expressions are strings interpreted by a binding provider. Elements carry approvals, risks, and controls, so UI governance is fine-grained - which is what makes agent-generated UI reviewable. Between design tools (specification over fidelity) and low-code platforms (no vendor lock-in), and deliberately smaller than IFML.
  • Bootstrap - Bootstrap elements as a model; one of the renderings of the UI model.
• Diagram - the common diagram vocabulary shared by the renderers and format bindings below.
  • Sprotty - Sprotty support
  • Presentation - the shared slide and page vocabulary behind the presentation formats below.
    • Draw.io - the Draw.io object model: diagrams as Ecore resources, read and written bidirectionally, which is what makes a diagram an authoring surface for the model rather than a picture of it.
    • PowerPoint - PowerPoint decks as model resources, read and written.
    • Visio - Visio diagrams as model resources, read-only - leverage your existing Visio assets.
    • PlantUML - PlantUML sources as model resources. PlantUML sequence diagrams can be used as animation specifications for Draw.io diagrams.
    • Mermaid - Mermaid sources as model resources. Mermaid sequence diagrams can be used as animation specifications for Draw.io diagrams. * ODP - OpenDocument presentations as model resources, read and written.
    • PDF - PDF files as Ecore resources.
• Maven - the POM schema as Ecore, which turns build files into architecture elements: dependencies become edges with semantics across federated repositories, and people named in POMs resolve to actors in the org model. Uses: dependency graphs, transitive vulnerability propagation, coverage across the estate, cross-technology tracing. Maven tooling reports one build at one moment, repository managers see published artifacts, SCA tools produce flat per-build lists; this supports organization-wide queries that combine ownership, governance status, and change impact.
• Tibco BW5 - TIBCO ActiveMatrix BusinessWorks 5.x projects, processes, activities, transitions, and inter-process calls, parsed from .process files down to activity level, with configuration retained as opaque XML so inventory-grade analysis does not require typing hundreds of adapter variants. Legacy processes become architecture assets that inherit governance, risk, lifecycle, ownership, and decision analysis - model-driven modernization where the register cannot drift from the code, from documentation generation through migration tracking to continuous scanning.
• CISO - a micro-model of the security program operations layer, the things a CISO runs that the rest of the tower oes not already model: incidents, vulnerabilities, awareness, resilience, third parties, and metrics.

Every model is a course

Every model here has a second job: it teaches its domain.

A generated model site is a concept map with depth. The diagram is the map: one look shows what the domain’s concepts are and how they relate. Each element is one bite-size page: a single concept, its documentation, and links to its neighbors - so learning proceeds one concept at a time, and every concept arrives already connected to the ones it depends on. The tower supplies the prerequisite structure the way a course catalog does: to read the CISO model you do not need to first master governance and threat, but they are one click below when a definition rests on them.

This is not a hypothetical. The CISO model was built by someone who knew little of the domain, from public bodies of knowledge; building it produced orientation, and reading it compresses that orientation into an hour. Certification bodies of knowledge load as framework catalogs, which makes a model a study companion: the linear book becomes a navigable graph.

The learning does not stop at reading, and this is the part that matters. Educational research on concept maps finds that studying a map helps, and constructing one helps substantially more. Customizing a model to your organization - anchoring your people, policies, and tools to its elements, extending its classes with your cases - is constructing the map. Each element’s documentation is a space, not a string: it can grow into a micro-wiki that links the org’s own pages, owners, and systems from the typed element they belong to. Adoption and learning are the same activity; the org that tailors the model ends up understanding its own enterprise, with the receipts kept.

The learning is also recordable: in the pull stack, people are capability providers, so a completed course or certification lands as dated, evidenced capability data - and a resume becomes a generated view rather than a source of truth.

A model is not a teacher: it will not give you judgment, and reading the CISO model makes no one a CISO. What it gives is fast, structured orientation and a scaffold that becomes yours - the thing tribal knowledge, slide decks, and wikis promise and cannot keep, because they have no structure to hang it on.

Beyond the tower

The tower is a curated slice. The Nasdanika-Models organization holds many more - platform and estate models (Java, Git, Kubernetes, containers, Azure, Terraform, SQL), execution and flow models, document and format models, and demo models used for teaching. Three of them carry weight for how the tower is used day to day:

• Jira - Jira issues and projects as a model, with a client, rate limiting, and snapshotting, so the quarterly state of a project hierarchy can be captured, enriched in passes, and analyzed later without re-querying a system that is not a system of record.
• Gitlab - GitLab users, groups, projects, repositories, and commits, loaded and cross-referenced with the rest of the model rather than re-scanned on every pipeline run.

Model Tree

One more way to think about the tower is as a tree - each model has a “trunk” class inheriting from the below class with twigs and leaves hanging off it. In some models it would be a ModelElement class extending and “shadowing” the lower floor ModelElement and implementing the primary class/interface of the floor.

For example

• ModelElement in NxCore with markers and documentation attached to it.
• Undergoer in Role with roles attached to it is an interface and ModelElement at the role floor extends the ModelElement in NxCore and Undergoer.
• Workable in Work.
• Element in Architecture.

“Primary/Trunk” classes are depicted on the model diagrams in “woody” color.