ea-mdg-model-build

Logic: AI + AI Power Tools checks. The AI plans and checks a long, order-sensitive procedure; deterministic operations do the model edits and exports; one build step is UI-only.

What it is for

Use it to manage a modeling language with a lifecycle: several versions, more than one author, or a metamodel your stakeholders review. You end with a technology file regenerated from the profile packages in your repository, with a version stamp, ready to deploy.

ea-mdg-model-build builds an MDG Technology from a source model held inside an EA repository (see Three ways to get a technology). The technology's definition is a tree of profile packages: stereotypes drawn as classes and bound to base types, tagged values as their attributes, plus a toolbox profile and a diagram profile. EA exports that tree into the technology file. The skill covers the whole cycle in eight phases, numbered 0 to 7: protect the baseline, lay out the package tree, apply the profile mechanics, handle reference data, build the toolbox, build, verify, deploy.

The file is regenerated from the packages on every build. That is the point of building from a source model, and also its constraint: the model is the only place to edit.

A technology with a lifecycle (several versions, more than one author, a metamodel stakeholders review) belongs here. A one-off technology or a patch to a shipped file belongs in ea-mdg-author.

Capabilities it uses

When to use it, and when not

A hand-authored file and a source model diverge permanently. Hand-editing the file of a model-driven technology means the next export silently discards the edit. Record the approach in the profile package notes. To move from a hand-authored file to a source model, import the file as a profile package first (Publish Technology > Import Package as UML Profile), then never hand-edit again.

How it works

The steps are the skill's phases.

0. (AI Power Tools; UI and file work: AI with computer use; otherwise you) Protect the baseline before touching anything. Baseline the source packages; confirm the current technology is imported and enabled; archive every artifact (profile files, the build definition, the MDG) into a Files package. Rename the baseline package roots unmistakably, for example [1.1.1 BASELINE - DO NOT EDIT].
1. (AI Power Tools, AI checks) Create the package tree. duplicate_package copies an existing tree with fresh identifiers. The AI verifies counts and records the package and toolbox-diagram identifiers of the copy.
2. (AI over AI Power Tools calls) Apply the profile mechanics. Stereotypes as classes, bound by Extension connectors, tags as attributes, Quick Linker rules as connector tagged values.
3. (AI, AI Power Tools reads) Handle reference data. Check which tagged value types already exist, carry enumeration domains over, check defaults against real values. Reference data goes through an ea-com script Engine or through EA's UI AI with computer use; otherwise you.
4. (AI Power Tools, AI checks) Build the toolbox and diagram profiles. Toolbox pages are elements on the toolbox diagram; entries are attributes.
5. (AI Power Tools, then AI with computer use; otherwise you) Build the MDG. publish_package_as_profile exports profiles. The assembly step is a UI step: Save Package as MDG Technology. The AI drives it by controlling EA's screen and reads EA's System Output window AI with computer use; otherwise you; without computer use you do it by hand.
6. (AI Power Tools, AI reads) Verify. Read the built file, compare it structurally with the source, run the "tagged value type shipped" check and look at the result in EA AI with computer use; otherwise you.
7. AI Deploy. Hand off to ea-mdg-deploy. A model-driven technology belongs at Location: Model, which keeps the toolbox profiles built in Phase 4. Check one entry at the right Location and version before validating anything.

Three surfaces, not one. There are three ways to do anything in EA:

The UI is not a fallback. A call tells you it returned; the UI shows what the model looks like and surfaces error dialogs EA raises instead of returning errors. Use them together. Using EA's automation interface needs local code execution; driving the UI needs computer use, and without it the UI steps are yours.

Phase 0: protect the baseline. Skipping this is the most expensive mistake available, because one step in Phase 3 is irreversible without leaving an error or a visible symptom.

• 0.4 gates Phase 3. Tagged value types are repository-wide. The moment a type belonging to the version being built is added, an export from the old profile packages stops being the old version, with no error and no visible change in the Browser.
• 0.1 needs the UI. Untick "Hide disabled Technologies" in Manage Technologies. get_mdg_from_runtime separates present-but-disabled from absent where it can read the technology's definitions: a disabled technology that the model stores, or that a registered file holds, reads as registered but not enabled, and "registered, not loaded" means registered, readable and not loaded. "Unknown id" for a technology with no readable copy cannot tell disabled from never installed. The AI drives the dialog and screenshots it AI with computer use; otherwise you.
• 0.6 matters more than it looks. A duplicated profile package has the same name as its source, so both trees show a child with the same name. Renaming the baseline root is the cheapest protection, and unlike locking it blocks nobody.
• Verify baseline scope. A package baseline covers the whole subtree; check that it holds what you expect. Use a length function that the repository's database supports: against a local .qea file (SQLite) a function that does not exist makes EA raise a modal dialog that blocks every later call until it is dismissed. With computer use the AI reads and dismisses it; without it you screenshot it, paste it into the conversation, then dismiss it.

Phase 1: package structure.

Model
|- <Tech> design metamodel V<n>     ArchiMate view, human-readable
`- <Tech> profile V<n>
    |- <Tech>  <<profile>>            stereotypes, base types, constraints
    |- <Tech>  <<diagram profile>>    custom diagram types
    `- <Tech>  <<toolbox profile>>    toolbox pages, one diagram per toolbox

The child package's stereotype routes its content into a section of the built MDG:

Stereotyping all three <<profile>> piles everything into the Profiles section and the other two come out empty (measured). Some published guidance says EA accepts either; measured, it does not.

A later version of an existing technology starts by duplicating the existing tree, which gives fresh identifiers on every package, element, attribute, operation and connector. A first version generated from a census has nothing to duplicate; see below. After duplicating:

• Verify the copy immediately: element, attribute, connector and diagram-population counts against the source, and no leakage back into the original's base types. duplicate_package copies the package's diagrams, their objects and links by default, so check the diagram population, especially for toolbox profiles, which hold one diagram per toolbox.
• Record the copied package identifiers and the toolbox diagram identifiers. The profile ids in the built MDG derive from them; that is how you later prove a file was built from the right source.
• XMI export and import is not a substitute: it does not dependably strip identifiers, and two packages claiming the same profile id is worse than a manual copy.

Phase 2: profile mechanics. These are modeling conventions, not an EA feature you can look up.

• Extension binds a stereotype to a base type. A stereotype with no Extension never exports: it sits in the profile package looking complete (tags, display name, constraints) and appears in no MDG. If a stereotype is missing from a built file, check its Extension first.
• Generalization is not an alternative to Extension, for any base. Measured on EA 17.1 build 1716: three builds made with Generalization came out with every stereotype extending nothing; converting the connectors to Extension restored every binding, an exact match to the authored file. The Profile toolbox lists Extension, Generalize, Tagged Value and Redefines; only Extension binds. (A Generalization between two stereotypes is a different relationship: it records that one stereotype derives from another.)
• Namespace-qualify every constraint value: WBA::WBABusinessApplication, never WBABusinessApplication. Unqualified constraints do not resolve and fail silently, and where enforcement is on, it is live against a rule that cannot resolve.
• Connector tagged values are scriptable with set_connector_tagged_value. update_connector ignores a tagged value passed as an ordinary property.
• Telling identical connectors apart. Two reflexive connectors on the same element are indistinguishable in EA's Relationships grid. Set a temporary name on the added one, do the work, clear it, and verify the clear.

Phase 3: reference data. Do not start before Phase 0.4 is archived. Tagged value types are repository-wide.

• Check what already exists first. A type is defined if its definition carries an enumeration with values or a date type. Types often exist and have only never been selected into a build (Phase 5). A tag behaving as free text does not prove the type is missing.
• Enumeration domains from a census are candidates, never the answer. Observation shows only the values that happen to have been used, so a domain derived from a repository is a lower bound. A value in use that no declared domain allows is a finding, not noise; a declared value nobody has used is usually fine. Where a technology is loaded, get_mdg_from_runtime returns its complete declared domains, which beat anything inferred; keep the observed values for the comparison.
• Check defaults against the values in use. A default absent from its own value list means the dropdown cannot round-trip data the repository already holds.
• Renaming a tag orphans its values. Fix spelling and trailing spaces before a production load, never after.

Phase 4: toolbox and diagram profiles. Toolbox pages are elements on the toolbox diagram; each page's entries are attributes on the page element. An entry's name is <Tech>::<Stereotype>(UML::<BaseType>), its default is the label shown in the toolbox, and its type is left blank (a populated type is a defect). Deleting a stereotype leaves its toolbox entry behind, so sweep the toolbox after every stereotype removal. A stereotype on no toolbox page ships invisible.

Phase 5: build. Two halves; only the first is scriptable.

1. Export each profile with publish_package_as_profile: the UML profile from the <<profile>> package, the diagram profile from the <<diagram profile>> package. Each toolbox exports from its diagram: use EA's automation call for saving a diagram as a UML profile Engine, or Publish Diagram as UML Profile in the UI AI with computer use; otherwise you (greyed out unless the diagram is open; selecting it in the Browser is not enough).
2. Build the MDG. The command depends on the EA version, and the two are not interchangeable.

Check the EA build first: get_repository_info reports the EA version.

The 17.1 and later build, step by step. These are UI steps AI with computer use; otherwise you: the AI drives them and screenshots each result.

1. Select the <<mdg technology>> package in the Browser.
2. Specialize > Publish Technology > Save Package as MDG Technology.
3. Choose the path in the Save As dialog.
4. EA reports "MDG Technology successfully saved to file".
5. Read System Output. It carries diagnostics the dialog does not, such as a duplicate-profile-name warning. A build can report success and still have collided.
6. Stamp the version. The generated file comes out with an empty version, and setting the package version beforehand does not carry through. Two unversioned builds are indistinguishable in Manage Technologies, and a file that declares no version reports none. Recording the version in the technology's description is one way to keep builds distinguishable.
7. Deploy through ea-mdg-deploy. The command installs nothing.

The technology id comes from the package name. Name the package for the id you want, in 12 characters or fewer: a longer name has been seen cut to 12 characters (WBA Technology became WBA Technolo) by one route and kept whole by another.

Save and Import are different commands. Import Package as MDG Technology is on the same menu as Save. Save writes a file and installs nothing. Import builds the same technology and imports it into the open model at Location: Model, toolbox pages included, and writes no file; install_mdg with the model scope does the same from a script. Measured on EA 17.1 build 1716. Import stores nothing at Location: Project, so a check of that Location reports a failure that did not happen. Verify an Import in Manage Technologies or with EA's loaded and enabled checks.

Always pass a version to publish_package_as_profile. EA reads a package's version the first time that package is published in a session and then caches it, so a later publish after changing the package silently returns the old value. The operation stamps the explicit version into the generated file and reports what EA would have shipped beside it.

Building before EA 17.1. The build definition cannot be hand-written: its schema is not published, and a reconstructed file is rejected for reasons nothing explains. Run the wizard once to emit a real one, keep it under version control, and edit that file afterwards. Match the wizard's Contents checkboxes to the shape of the currently deployed file (profiles, tagged value types, diagram types, toolboxes). The Tagged Value Types page is a selection step: a type not selected there does not ship, however completely it is defined. This is the usual cause of "the type exists but the field is still free text". Use stable unversioned filenames in the build folder: the build definition references the profile files by filename, and a stale one silently ships the previous version's content.

Phase 6: verify. Verification is mechanical: read the built file and compare it with the source.

• The check that catches the expensive mistake: the four profile identifiers must match the V<n> package and diagram identifiers recorded in Phase 1, not the previous version's. A correctly versioned file built from the wrong source passes every other check. A profile id is a 10-character slice of the package's identifier.
• A full structural comparison is worth automating. For each stereotype, compare its base type, what it derives from, color, tags and constraints in both files. Anything other than the intended differences is a finding.

Checklist:

• [ ] Profile ids match the current source packages
• [ ] Every added stereotype is bound to a base type. (An empty binding is the symptom of a missing Extension, and the stereotype will not appear.) "Derives from" is only populated where a stereotype derives from another stereotype; empty is not a fault
• [ ] Every constraint value is namespace-qualified
• [ ] Widened constraints list all targets, semicolon-separated
• [ ] Removed stereotypes are absent, and similarly named ones still present
• [ ] Added tagged value types are on their stereotypes and in the file's reference data
• [ ] All profiles are stamped with the version being built

Match on exact strings, never prefixes: profiles routinely contain near-identical names whose blast radius differs by an order of magnitude. The "tagged value type shipped" condition of ea-validation automates the reference-data check: it compares a profile's blank-type tagged value attributes against a built file's reference data and flags anything defined but not shipped.

Phase 7: deploy. A technology is deployed either into the repository (seen by everyone who connects) or as a file registered on a workstation (seen by that machine). They look identical in Manage Technologies apart from the Location field.

A model-driven technology belongs at Location: Model: it is the only in-model Location that keeps the toolbox profiles built in Phase 4.

EA auto-registers any MDG file found on its search path (Manage Technologies, Advanced tab), and the path routinely includes a user's Downloads folder. A build written there registers itself, shadows the model copy, and makes deployment look successful on the author's desktop while nothing changes for anyone else. The search path is not recursive: a subfolder is safe. Before validating, confirm in Manage Technologies, with "Hide disabled Technologies" unticked, one entry at Location: Model carrying the expected version. Then import, confirm enabled rather than merely present, restart EA (until then the toolbox may not switch to the technology's pages, although they are loaded), and validate on a scratch diagram (toolbox page, Quick Linker, tag dropdowns) before touching content. Measured for the Westbrook technology 1.1.1 after a restart: each of its three diagram types opened its own toolbox page (12, 5 and 5 items), and a dragged item came out bound to the technology.

Generating the profile tree from a census. This is the first-version case: nothing to duplicate. Come here from ea-mdg-assess, where building from a source model is chosen and recorded.

1. Engine Census first, profile-aware. It supplies each stereotype with its base type, tag names with populated-value coverage, and inferred enumeration domains: the content of the profile about to be created.
2. Create the four packages one after another. EA's package tree is not thread-safe, and parallel creates produce intermittent errors.
3. Stereotype the three child packages correctly (table in Phase 1).
4. Name the technology package for the id you want (12 characters or fewer; see above).
5. Create one base-type element per distinct observed base type, then one stereotype element per stereotype and base type pair, then an Extension connector from each stereotype to its base type.
6. Carry the census's tag names onto the stereotypes as attributes. Phase 3 covers the reference-data half.

Verify by round trip, not inspection. Build the technology, install it, and re-census the repository through the generated technology Engine. The generated MDG should describe the content it was derived from; anything the re-census reports as undeclared was dropped by the generation.

Gotchas

Working rules

• Ask before writing queries against a live repository, and never assume execute_sql is read-only: it accepts writes.
• Never edit the baseline packages. Protect them by renaming; lock only where you know who the lock applies to.
• Do not fix things out of sequence. A toolbox defect found during profile work is recorded, not corrected: nothing exports until the build phase, and out-of-sequence edits are how verification stops meaning anything.
• Measure against the repository, not against the plan. Counts in planning documents go stale, and a sandbox is not production.

What you get

• A baselined, archived starting point and a source model that stays the single place to edit.
• A built, versioned MDG file whose contents were compared with the source structurally.
• The build diagnostics (System Output text) quoted back, including any warning EA raised while calling the build a success.
• A deployed technology with one entry at the right location, or the file ready for ea-mdg-deploy.

Tools it relies on

• duplicate_package, create_package, update_package: Packages
• create_element, create_connector, set_element_appearance: Elements, Connectors
• create_attribute, update_attribute, delete_attribute: Class members
• set_connector_tagged_value and siblings: Tagged values
• create_baseline, list_baselines, compare_baseline, apply_baseline (destructive), get_repository_info: Baselines, Project
• publish_package_as_profile: Publishing a profile
• install_mdg with the model scope, and get_embedded_mdgs to read what the model stores: Managing technologies, Discovering technologies
• get_mdg_from_runtime, parse_mdg_xml: Discovering technologies, Authoring
• execute_sql (reference-data and baseline reads): Direct queries
• ea_validate audit: ea_validate
• EA's automation interface through ea-com (needs local code execution), and the AI driving EA's screen (computer use), for saving a diagram as a profile, reference data and Save Package as MDG Technology
• The census helper (an engine: needs local code execution): Shared references

Sample prompts

1. "WBA 1.1.1 is deployed. Start a 1.2 build: baseline the source packages and show me what you will protect before you duplicate anything."
2. "Add an Application Owner tag to WBABusinessApplication in the model and rebuild the technology."
3. "A WBA stereotype is in the profile package but missing from the built MDG. Find out why."
4. "Build the MDG from the WBA technology package on this EA, and tell me what System Output said."
5. "Generate a technology from this repository's stereotype usage and keep a source model for it. Create the profile packages."
6. "The type for lifecycle exists in the repository but the dropdown is free text in the deployed technology. Why?"

Recommended models

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

Checking accuracy and completeness

1. Source-version proof. The four profile ids in the built file equal the 10-character slices of the current V<n> package and toolbox-diagram identifiers recorded in Phase 1. Red flag: ids matching the previous version.
2. Structural comparison against the source. For each stereotype, compare base type, derivation, color, tags and constraints between the built file and the source tree. Correct: only the intended differences appear. Red flag: a stereotype in the profile package and absent from the file, or bound to no base type.
3. Count reconciliation after duplication. Elements, attributes, connectors and diagram populations equal the source (duplicate_package returns counts; its verbose form returns the identifier maps). Red flag: a connector whose endpoint is in neither the identifier maps nor outside the subtree.
4. Reference data shipped. Run the "tagged value type shipped" check against the built file. Correct: no violations, and the added tagged value types appear in the file's reference data. Red flag: a defined type absent from the file.
5. Every stereotype is reachable. Each appears on a toolbox page, and no toolbox entry names a deleted stereotype.
6. Constraint qualification. Every Quick Linker constraint value is Tech::Name.
7. Single deployed copy at the right Location. Manage Technologies, "Hide disabled" unticked: one entry, at Location: Model, with the expected version, and no copy of the same id at Location: Project; and get_mdg_from_runtime answers live with no version mismatch and no second copy named.
8. Build diagnostics read. The System Output text from the build is quoted, including any duplicate-profile-name warning.
9. Version stamped. The built file's version is not empty.
10. Census round trip (generation case). Re-census through the generated technology; nothing is reported undeclared.

Limitations

• Save Package as MDG Technology is done in EA's user interface. The AI drives it through computer use; without computer use you do it by hand.
• It exists only on EA 17.1 and later. Earlier builds use the MTS wizard, and its build definition cannot be hand-written.
• Generated files come out unversioned, and the package version does not carry through.
• The id comes from the package name, and a name over 12 characters may be cut to 12 or kept whole depending on the route. Name the package for the id you want, in 12 characters or fewer.
• Reference data goes through EA's automation interface (local code execution) or the UI (computer use).
• Import Package as MDG Technology writes no file. It imports into the open model at Location: Model, as does install_mdg with the model scope. Use Save Package as MDG Technology when a file is wanted.
• A hand-edited file diverges from its source model silently.
• Deletes through the automation interface cannot be undone. Baseline first.
• ClassifierID references are not remapped by duplicate_package. That does not affect untyped profile-mechanics attributes but would for a subtree relying on internal classifier typing.
• EA can block on a dialog. EA reports many failures as a modal dialog that waits for a person and blocks every later call, so a call that seems to hang is usually waiting on one (see Shared references). With computer use the AI sees the dialog in EA's window, reads it, uses the message to correct the call, dismisses it and carries on. Without computer use you screenshot the dialog and paste it into the conversation so the AI can analyze it, then dismiss it so processing can continue.