Catch a non-conforming change

Goal

Show governance working at the moment of change: an architect adds a component to a project, and validation flags what does not conform before it is promoted. This is for a solution architect and an architecture review board. You end with a worked example in which three kinds of defects in a draft are found and corrected, and a re-check comes back clean.

This scenario is a worked illustration on the Westbrook customer-portal project. Substitute your own project, services and standards.

Where it runs

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

What a ruleset can and cannot catch

State this plainly, because it is the point of the scenario.

• A ruleset can catch the missing governance tag. It is a required-tag rule with a value filter, which the audit evaluates directly.
• A ruleset cannot catch the wrong connector type, or the dependency on a deprecated service. The audit's rules select connectors by one stereotype and test the stereotypes at the connector's ends. They cannot tell a portal from any other business application, and they cannot read the lifecycle tag of the element at the far end. These two defects are caught by the assistant's own review of the new element's connections.

The assistant's review is useful and repeatable, but it is a reviewed finding, not a ruleset violation, and the assistant should say so.

The project

Westbrook builds a customer portal with AI features (a conversational assistant, personalized insights, document understanding) and a new central AI gateway. The gateway does not exist in the repository yet. The architect has the assistant draft it from the project brief, approves the draft, and the assistant creates the element and its connections. Governance then checks the result.

The draft contains three deliberate problems:

1. A connector-type substitution. The portal is connected to the gateway with a Uses connector, where Westbrook's convention for portal-style consumption is ConsumesService. In this illustration ConsumesService is a proposed convention: the WBA technology declares three connector stereotypes (Uses, Flows and realizes), and ConsumesService is not one of them.
2. A missing governance tag. The gateway is Mission-Critical and its modelGovernanceClass tag is blank. The tag feeds Westbrook's model-risk workflow, so an element without it cannot be registered.
3. A dependency on a deprecated service. The draft connects the gateway to a legacy data export feed whose lifecycle is Deprecated, where the current Customer Profile Service (lifecycle Strategic) is the intended target.

The contrast is between a mechanical check, which finds problem 2 every time, an assistant review that finds problems 1 and 3 by reading the connections, and architectural judgment, which decides what to do about problem 3. Problem 3 is not auto-fixable: replacing a dependency can change behavior, so the architect decides.

Before you start

• A repository with the portal application, the Customer Profile Service and the deprecated feed (illustrated here by Westbrook's model). Substitute your own.
• A governance ruleset for the project (see Author a ruleset) and a statement of the connector-type convention.
• A baseline of the package the change goes into. The assistant offers it; see Protect a change with a baseline.

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, and ea-change-management takes a baseline of the target package. You accept the baseline.
2. AI ea-modeling drafts the gateway and its connections from the brief. You approve the draft; AI Power Tools then creates the element, sets its tags and creates the connectors.
3. AI Power Tools ea-validation runs the project ruleset on the package, using the quick-check subset. This finds problem 2.
4. AI ea-modeling and ea-model-hygiene check what the ruleset cannot express: it lists the new element's connections, reads each connector's stereotype against the convention, and reads the lifecycle tag of each service the gateway depends on. This finds problems 1 and 3. You review the flags.
5. AI ea-validation explains each finding and proposes a fix. You decide.
6. AI ea-modeling applies the fixes you approve and leaves problem 3 for you to decide; AI Power Tools makes each edit. You approve per fix.
7. AI Power Tools The assistant re-runs the audit and the connection review, then ea-diagram-composition renders the diagram. AI with computer use; otherwise you look at the corrected diagram in EA's window.

The expected findings

For finding 2, the expected audit result is one error-severity violation naming the gateway, with a message saying the required tag is empty and the rule's remediation text.

Prompts to use

Opening:

Follow-ups:

• Create: "Looks right. Baseline the package, then create it."
• Validate: "Run the project governance rules on the package. Then check the new connectors yourself: the convention for the portal connector, and the lifecycle of every service the gateway depends on."
• Decide: "For each finding tell me what the fix is and whether it is safe to apply automatically."
• Close: "Fix findings 1 and 2 with my approval. Leave the dependency for me to decide. Re-run everything and render the diagram."

Recommended models

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

Checking the result

• Correct. The audit's violation for finding 2 names the right element and tag. For findings 1 and 3, each connector the assistant flagged has the stereotype and target lifecycle it claimed; open the connector and the target element in EA to confirm. Red flag: a finding the assistant cannot back with the stored stereotype or tag.
• Complete. List every connector of the new element and confirm each was assessed, not only the ones that were flagged. Red flag: a connector the assistant never mentioned.
• Nothing unintended changed. A baseline comparison shows only the new gateway, its connectors, and the fixes you approved. Nothing in the deprecated feed's own package changed.

Variations

• Run the same ruleset on a whole repository as a periodic health scan rather than at change time.
• Replace the three problems with your own project's standards. Any required tag with a value filter fits the ruleset directly; anything about a connector's stereotype or a neighbor's tag stays with the assistant's review.

Limitations

• A ruleset for this project, as designed, would need constructs the shipped audit does not have (a source scope, a lifecycle comparison, a "must use this connector type" constraint). Do not paste such a ruleset into the audit expecting it to work.
• A model may carry informal connector stereotypes that came from no technology, with inconsistent case (realizes and Realizes are different strings to the audit). A rule that names a stereotype misses spelling variants silently.
• ConsumesService is an illustrative convention. If your standard names a connector stereotype, confirm it exists in your model before writing a rule against it.