How to trust the result
An AI that finishes a task and says it is done has made a claim. These methods turn the claim into evidence. Every scenario ends with Checking the result, and every skill lists the checks that suit it. This page is the common method behind them: six ways to check, a recipe for any task, and the check that fits each kind of task.
Accuracy and completeness are different questions. Accuracy asks whether what is there is right. Completeness asks whether anything is missing. A check can pass one and fail the other. A count that matches proves completeness for that count. It does not prove the elements are the right ones.
The six methods.
| Method | How | What it proves | What it does not prove |
|---|---|---|---|
| Count back | A counting query by stereotype, package or connector type, compared with the number the plan or source called for. Scope it to the same subtree as the work | That the right number of things exist | That they are the right things, in the right package, with the right properties |
| Render and look | verify_diagram always reloads the diagram, renders it, and returns the canvas extent, every placed object with its rectangle and stacking order, every link with its route, and quick counts. Ask for the SVG to check what color EA actually drew. Then look at the picture |
That elements are placed, inside the canvas and not stacked, and that links exist. Geometry can be read as numbers | That the picture reads well to a person. A diagram can pass every number and still be unreadable |
| Run validation | ea_validate audit with a ruleset, scoped to a package. Test each rule first on a known-bad element: it must fail where it should |
That the checked conditions hold or fail, repeatably | Anything the rules do not cover. A rule part the engine does not recognize is skipped silently, so a rule that never fires has not been proven to work. See Validation engine |
| Check the business layer | In the reporting-database skill, the alignment check measures the layer against the technology's metamodel, in counts. The value check compares every cell with an independent read through EA and reports the cells compared and the differences. A check that read no cells fails and never passes | That the layer follows the technology and equals EA's content as of the check, cell by cell | That the technology is the right one, or that what the inclusion choice left out does not matter. It applies to the two database delivery ways. See ea-reporting-database |
| Compare a baseline | Take a baseline before a change, then compare after. The result lists items that are model-only, baseline-only, changed and identical, with the changed properties | Exactly what changed, including changes nobody intended. This is the check for "nothing else moved" | Whether a change is correct. It reports differences. It is no use if the baseline was never taken |
| Spot-check in EA | AI with computer use; otherwise you Open the diagram or element in EA, reload it, and compare what you see with the intent. In Specialize > Technologies > Manage Technology, confirm a technology's state. See ea-ui-verification.md | What a person will actually see, including a dialog the API cannot report | Coverage. It is a spot check, so combine it with a count |
A recipe for any task.
- Write down what "right" looks like before running: the expected counts, stereotypes, packages, properties and picture.
- Take a baseline before a change that could affect more than you intend.
- Do the work.
- Count back against the expectation, scoped to the work.
- Read back a sample in full (
get_element,get_element_tags) to check properties and not only existence. EA keeps tagged values in several places, so read tags through the operation and not by guesswork. - Render and look at any diagram, with
verify_diagramand then your own eyes. - Compare with the baseline for unintended changes.
- Run a ruleset if the model has one, after proving it on a known-bad case.
- Report what was checked and what was not. "Counts match, diagram verified, tags sampled at ten percent, ruleset not run" is more useful than "done".
Quick reference by task.
| The task | The check that fits |
|---|---|
| Created N elements | A count by stereotype and package, and a sample read-back of tags, compared with the plan |
| Created or edited a diagram | verify_diagram, then look at it. Expect nothing off-canvas and nothing stacked |
| Changed tagged values | Read tags back. For a roll-up, check how many values are populated next to how many are present, because a tag that exists but is empty counts for nothing. summarize_tagged_value_usage reports both |
| Moved or deleted things | A baseline compare before and after. For deletes, the pre-delete checks in ea-model-hygiene |
| Exported XMI, a document or an image | Check that the file exists, is not empty, and holds the package's elements. export_xmi verifies that the output contains the package's elements |
| Wrote or refreshed diagram descriptions | audit_diagram_descriptions: each diagram reads current, and a diagram that waits for a decision is listed with nothing written to it |
| Built a business layer or a Power BI model | The layer aligned with the technology, the value check with cells compared above zero and no differences, and the Power BI table, relationship and measure counts equal to what the generator printed |
| Authored a ruleset | A known-bad element for each rule, and no violations on a known-good one |
| Built or deployed an MDG Technology | get_mdg_from_runtime for the technology, a created element that carries the stereotype, and the Manage Technology view |
| Did a task through the user interface | A read-back through an operation or a query, not the dialog |
Package depth. Subtree counts and walks cover the full depth of a package tree and report the depth they reached. When a count looks low, check how deep the walk went. See How tools and operations work.
overviewoverview