Protect a change with a baseline

Goal

Take a snapshot of a package before a bulk or destructive change, compare afterward, and either keep the change or roll the package back. This is for a modeler or architect about to restructure, import, bulk-edit or delete. You end with a named baseline, a readable account of what the change did, and (if the change was wrong) a verified restore, with unneeded baselines cleaned up.

Where it runs

This scenario needs the MCP server. Computer use covers its UI steps.

How baselines work

EA's baseline mechanism stores a compressed snapshot of a package subtree inside the repository itself. This scenario covers the full cycle: decide whether and where to baseline, create it, make the change, read the comparison, and, if needed, restore.

Restoring is the part that goes wrong most often. Applying a baseline (apply_baseline) replaces the package's content wholesale. It is not a merge and not a selective revert, and it discards every change made in that package since the baseline, including other people's.

The skill offers a baseline proactively, once, before the kinds of change that justify one. It does not offer on small edits, because offering on everything bloats the repository and teaches people to click through.

This is EA's own baseline feature, held inside the repository: in the .qea or .qeax file for a local file, or in the shared database for a server connection or a cloud connection. It is not for models kept under source control as exported XML files, which is a different workflow.

Before you start

• EA is running and the right model is open (preflight). A baseline taken against, or applied to, the wrong model wastes the work.
• You know the package to protect. The assistant finds it from the package tree or by name (Packages).
• For a restore: coordinate with anyone else working in that package. Reads are safe at any time; applying a baseline is not.

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-start-here runs the preflight. You confirm the model.
2. AI ea-change-management decides the scope: the narrowest package that contains the change, and the model root only for model-wide operations. You confirm the scope.
3. AI ea-change-management offers a baseline before a triggering change, stating the operation, the scope and the size. You accept or decline.
4. AI Power Tools ea-change-management creates the baseline (create_baseline) with a version label and notes, and lists the baselines on the package (list_baselines) to confirm it. See Baselines.
5. AI The change itself happens, through ea-modeling or another skill, as it normally would.
6. AI Power Tools ea-change-management compares the package with the baseline (compare_baseline).
7. AI ea-change-management summarizes the comparison. You decide: keep the change, or restore.
8. AI Power Tools If restoring, ea-change-management first takes a fresh baseline of the current state, then re-confirms the package and the baseline, then applies the baseline (apply_baseline). You give explicit confirmation.
9. AI Power Tools ea-change-management verifies the restore by reading the package back.
10. AI ea-change-management reviews the baselines for size and deletes only those you name. You confirm each deletion.

Step 2, scope. Pick the scope by what you are protecting against:

A baseline always covers the whole subtree under the package.

Step 3, when the assistant offers. It offers before these and not otherwise:

Twenty-five is the skill's stated line, a judgment call. Adjust it for your deployment and say what number you use. The assistant asks before the triggering change, names the package and the approximate size, and offers a choice between taking the baseline first and proceeding without one. A decline is remembered for the rest of the session, per trigger category. A new session starts clean.

Step 4. Use a version label you will recognize later (2026-10-06-pre-restructure) and put the reason in the notes. The assistant keeps the baseline's identifier.

Step 5, reading the comparison. The result shows the baseline's details, the live counts of elements, attributes and connectors in the subtree, and each item and each property with one of four statuses:

Identical rows are counted but not listed by default. The comparison also opens EA's own comparison view as a side effect. The connector count in the live figures counts only connectors whose start element is inside the scope.

Step 8, restoring. Do all four of these before applying a baseline:

1. Take a fresh baseline of the current state. It is the undo for the undo.
2. Re-list the baselines and re-confirm the package and the baseline.
3. Coordinate with anyone else working in the package.
4. State plainly what will be discarded.

The restore verifies itself: afterward it compares the package against the baseline again. A result of "applied" and "restored" means EA reports no remaining differences. If differences remain, the assistant reports that nothing changed. Read that as "nothing changed", not as a partial success. The operation always carries a warning that it overwrites current model content. Verify by reading the package back either way.

Step 10, cleanup. Baselines live inside the repository, and the assistant lists them with their sizes and deletes them with a direct database statement only after naming each one (version, notes, size) and getting your yes. It then re-lists the baselines to confirm. The baseline listing is reported to show date and author empty; if you need a trustworthy timestamp, ask the assistant to read it from the repository itself.

Prompts to use

Opening:

Follow-ups:

• Change: "Go ahead and make the changes we agreed."
• Compare: "Compare the package with the baseline. Group the result into added, deleted and changed, and show old and new values for the changed ones."
• Restore: "That went wrong. Take a safety baseline of where we are now, confirm the package and baseline you'd restore, then restore and verify."
• Cleanup: "List the baselines on this package with sizes. Don't delete anything yet."

Recommended models

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

Checking the result

• Correct. The baseline listing shows the baseline with the version and notes you gave. After the change, the comparison lists exactly the items you expected, and each changed item shows the right before and after values. After a restore, the result says applied and restored, and a read-back of the package matches the baseline's contents. Red flag: a comparison that lists items you never touched.
• Complete. The item count equals the sum of the per-status counts; if it exceeds the number of listed items, identical items were withheld, not lost. The live counts match what you expect the package to hold.
• Nothing unintended changed. Before a restore, check that no one else edited the package since the baseline (see Find out what changed, when and by whom); a restore would discard their work. After cleanup, only the baselines you named are gone.

Variations

• Before an MDG rollout (ea-mdg-deploy): baseline the model root, because the rollout reclassifies existing elements.
• Before acting on an audit's findings (Validate a model against a ruleset): baseline when the fix touches more than 25 elements.
• Before an XMI import (Move content in and out of Enterprise Architect): baseline the target package.
• A heavier-weight use of the same feature: ea-mdg-model-build renames and locks a protected package root before an MDG rebuild. Same EA feature, different purpose.

Limitations

• Applying a baseline is destructive and has no undo. It overwrites the package subtree wholesale, including other people's concurrent edits. Never apply a baseline you did not take for this purpose.
• Each baseline adds a compressed blob to the repository. Baselining large subtrees often grows the file. Check sizes before making it a habit.
• A call that appears to hang is usually a dialog box in EA, raised when EA cannot run a query. It holds the connection until someone dismisses it. With computer use, the assistant sees the dialog in EA's window, reads it, uses the message to correct the call, dismisses the dialog and keeps going. Without computer use, you take a screenshot of the dialog and paste it into the conversation so the assistant can analyze it, then you dismiss the dialog so processing can continue. Then the call is retried.
• A write EA rejects can be reported as success. Read the package back after any restore or bulk change.
• The comparison is package-level. It opens EA's comparison view as a side effect.
• Baselines are not a substitute for a backup of the model file. They live in the same repository.