Generate an MDG Technology from current usage

Goal

Turn the stereotypes, metaclasses and tagged values that a repository actually uses into a formal technology. For an MDG author, or a methodologist adopting a model that grew without one. You end with a technology, as XML or as a source model, that describes the content it was derived from, with the choice of path recorded and the generation checked by a second census.

Where it runs

This scenario needs the MCP server and local code execution. Computer use covers its UI steps.

Before you start

• The start-of-session check and Assess the language situation. The assessment is typically situation 1, or situation 3 for a technology that exists but is surrounded by ad hoc use.
• A representative repository. A census of a half-built model describes a half-built language.
• Local code execution: the census is a code engine (Code engines). Without it the scenario is not available.
• To build from a source model: everything in Build an MDG Technology from a source model, including EA 17.1 and the baseline.
• The same census can feed a reporting database. If that is the real goal, go to Build a reporting database: the census work is identical and only the output differs.

A repository with no technology is rarely a repository with no modeling language. It usually has one that is undeclared, inconsistent and spread across however many stereotypes people reached for. Those stereotypes, their metaclasses and their tagged values are a candidate metamodel. This scenario censuses them, shapes the candidate, and generates a technology from it.

The census must be profile-aware. The stereotype stored on an element is a bare name that does not identify its language. In one repository, one bare name resolved to a TOGAF stereotype, another to a BPMN one, and several ArchiMate-looking names to no profile at all. The profile binding lives elsewhere in the model, and the skills' census module resolves it. It treats provenance as "a profile name is present", not "a row exists", parses several stereotypes on one element, and reports exclusions: EA's own stereotypes, and profile-authoring ones. The same rule applies to connectors: a connector stereotype is bound to a profile or it is ad hoc, and the census reports which.

Two approaches, and the choice is one-way.

Steps

1. AI with computer use; otherwise you If EA is not running or the model is not open, start EA and open it. AI Power Tools ea-mdg-assess runs the start-of-session check and the assessment.
2. Engine ea-mdg-assess and ea-reporting-database run the profile-aware census over the repository. It returns each pair of stereotype and metaclass, and for connectors each pair of stereotype and connector type, with the profile each is bound to or the word ad hoc. It also returns tag names with populated-value coverage (a tag present on every element and filled in on none is not covered), and inferred enumeration domains. The stereotype tally, the tagged-value tally and the observed-metaclass tally in ea_analyze reach part of the same ground: they report profile binding, populated counts, and a stereotype's metaclass distribution. The skill's text still points to the census module for the full picture.
3. You Review the census and decide what to bless, merge, rename or leave out. Three findings change the decision. A name used both ad hoc and profile-bound: if most usage is already bound, you are extending a technology, not creating one. Stereotypes from other shipped languages: EA enables every language it ships, so an architect reaching for "Application Component" can land on TOGAF's without noticing, and generating a technology that blesses the accident makes it permanent. Tag-name shape: an element carrying your tags while labeled with another language's stereotype is a misassignment, and the census reports it as one.
4. You Choose the approach, and record it with the date and the words "generated from a census": on the profile package notes when building from a source model, and in the technology's documentation notes when writing the XML directly. A generated technology looks identical either way, so unrecorded, the next maintainer cannot tell.
5. Writing the XML directly: AI ea-mdg-author shapes the metamodel in the form write_mdg_xml takes, then AI Power Tools writes and reads back the file (write_mdg_xml, parse_mdg_xml). You Approve the display names. A census gives names, not display names, and mechanical case-splitting cannot see into an all-caps prefix: WBABusinessApplication would split into the wrong words. Strip the known technology prefix first, then split, and say which prefix you stripped. Where a technology is loaded, the runtime reading supplies real aliases, which beat anything derived. Derived display names are customer-facing text. The effective limit on the technology id is 7 characters (Hand-author an MDG Technology). An id taken from a package or profile name will often be too long: shorten it deliberately rather than truncating. A census finds connector stereotypes as readily as element ones, and an observed connector stereotype is often another language's relationship, so check the profile binding before promoting one. A qualified name typed into a connector's stereotype field with no binding behind it is a data defect to fix in the repository, and not a stereotype to promote.
6. Building from a source model: AI Power Tools ea-mdg-model-build creates the four packages from the census, one at a time, stereotypes the three children (see Build an MDG Technology from a source model, step 3), names the technology package for the id you want, creates one «metaclass» element per observed metaclass and one «stereotype» per pair, adds an Extension from each stereotype to its metaclass, carries the tag names across as attributes, and then continues through Build an MDG Technology from a source model. You Approve the result.
7. You Settle enumeration domains. An inferred domain is a lower bound: observation can only show the values that happened to be used. A value in use that no declared domain allows is a finding, not noise. Importing the observed set silently blesses it. A declared value nobody used is usually fine and should not be pruned.
8. You Deploy (Deploy an MDG Technology and prove it works).
9. Engine ea-mdg-model-build runs a second census through the new technology. It should describe the content it was derived from. Anything the second census reports as undeclared is something the generation dropped.

Prompts to use

Opening

Follow-ups

Recommended models

Ratings are guidance based on the kind of reasoning the skill needs, not measured benchmarks.

Checking the result

• Accurate. The generated technology reads back to the same stereotypes, metaclasses and tags as the reviewed candidate. The second census, run through the new technology, shows each in-scope element bound to the profile.
• Complete. The second census reports nothing undeclared that you meant to include. Every exclusion (EA-internal and profile-authoring stereotypes) is stated, with its count. Enumeration domains are marked as inferred or declared.
• Nothing unintended changed. Writing the XML directly writes nothing to the repository until deployment. Building from a source model adds profile packages, and nothing else differs from the baseline. Existing elements keep their stereotypes: generating a technology does not migrate them.

Variations

• Declared against observed. Where a technology already exists, the same census compares what it declares with what is used. See Compare declared and observed usage.
• A queryable extract. If the goal is a database and not a technology, use Build a reporting database.
• Continues as Build an MDG Technology from a source model. Building from a source model ends in the same build, stamp, verify and deploy steps.

Limitations

• The path choice is one-way. See the warning on choosing the scenario in Governance.
• A generated technology ships no reference data. AI Power Tools writes an empty reference-data section, so an enumeration the census inferred, or the full domain a technology declared, stays free text. Say so when you hand it over.
• The census is a snapshot of usage. A half-used model produces a half-formed language, and observation cannot see values that have not yet been used.
• Two names for one concept. The same stereotype name can be both ad hoc and profile-bound, and the census reports that split. Resolve it by a decision, not by merging silently.
• Display names are guesses. Review them.