ea-reporting-database

What it is for

Use it to make the repository queryable in your business vocabulary, by an agent, a SQL client or Power BI. You end with a business layer with tables named as your modeling technology names them, checked cell by cell against the repository.

ea-reporting-database builds the business layer for an EA repository and proves that it matches the repository. The business layer is a set of tables named and shaped by the modeling technology that governs your model: one table per element stereotype, one per connector combination the technology allows, tag-row tables where a column cannot hold the data, and a Table Directory. It sits over a scoped copy of, or scoped views over, EA's own tables. An agent, a SQL client or Power BI reads it.

The idea is that the tables are your business vocabulary. A repository governed by a technology that declares a WBABusinessApplication stereotype with the alias "Business Application" gets a Business Application table with one typed column per declared tagged value, not a generic table of EA elements. The names are exactly the technology's: no prefix is stripped and the case is kept.

The skill delivers the business layer in one of three ways, and the layer is the same on every way: the same names, columns, types and rows.

1. Views in the EA repository's own database. The business layer is built as SQL views, in a schema of their own, inside the SQL Server database that holds the EA repository. EA's own tables reach Power BI through scoped views in the same schema. It needs direct access to that database and the right to create views in it, and EA's tables are never altered. The data is live: the views read EA's tables as they stand.
2. A separate reporting database. AI Power Tools reads a scoped copy of EA's tables through Enterprise Architect, so no direct database access is needed. It loads the copy into a separate reporting database, on a SQL Server you run or in a SQL database in Microsoft Fabric, in EA's own table shapes, and builds the same business-layer views there. The result is a snapshot, rebuilt in full on every refresh, and queries never touch the EA database.
3. Parquet files, with no database. The same scoped copy is read through Enterprise Architect, and AI Power Tools computes the business tables' rows. A code engine shipped with the skills writes one Parquet file per table into a local folder, together with the Power BI project that reads them (ea-power-bi). The result is a snapshot, rewritten on every refresh.

The build itself runs in the AI Power Tools MCP Server for Sparx EA, through seven operations described in Reporting business layer. The skill drives them and puts the decisions to you. Code engines run the census behind the inclusion choice and the governance gate.

The skill changes the model only through the governance gate's stereotype application, behind a baseline, and only when you choose it. Fixing a connector that blocks the build is also a model change, made in EA after a baseline. Views in the EA database add views to the EA database, in their own schema, but never alter an EA table.

Capabilities it uses

The work on SQL Server needs neither code execution nor extra software: AI Power Tools reaches SQL Server through the database providers Windows already has. A reporting database in Microsoft Fabric needs the Microsoft OLE DB Driver for SQL Server for its Microsoft Entra sign-in (see "Where the reporting database runs" below).

When to use it, and when not

The business layer needs a modeling technology. It is shaped by a technology's metamodel, so a repository with no technology loaded has nothing to build it from. The AI says so and does not build.

How it works

1. Run the session preflight and open the model. (AI Power Tools, then AI with computer use; otherwise you) ea-start-here confirms which repository is actually open and which technologies are loaded; both change the output. If EA is not running, it is started and the model opened.
2. Read the technology. (AI Power Tools, then AI) get_mdg_from_runtime returns the technology's stereotypes, aliases, descriptions, declared types and allowed relationships. The AI checks that EA answered from the loaded technology. With no technology loaded, the AI says so and stops.
3. Choose the delivery way. (AI, then you) The AI puts all three ways to you at once, each with its consequence, then waits. You answer from the facts of your estate (see "The three ways of delivering the data" below).
4. Set the scope. (AI Power Tools, then you) The root packages to include and the packages to leave out, read with direct queries. You confirm the scope.
5. Take a census over the scope. (AI Power Tools, then engine) The element and connector rows are read with direct queries; the census and its analysis against the technology run as code engines.
6. Stop on unbound connectors. AI with computer use; otherwise you A connector whose stereotype is stored as qualified text with no binding to the technology is a defect in the repository, not a question for you. It is fixed in EA, after a baseline, and the census is taken again. No profile is written while any remain.
7. Decide on elements with two declared stereotypes. You They are flagged with the count. If you continue, each is placed in both tables.
8. Make the inclusion choice. (AI, then you) The AI puts the three answers to you, with their counts, every time a profile is created. You answer (see "The inclusion choice" below).
9. Write the reporting profile. AI The profile records your scope, your inclusion choice with a record of it, the technology and the delivery way. Where the AI cannot write a file on the machine, it gives you the content to save.
10. Run the governance gate. (engine, then you) The gate lists the in-scope elements whose stereotype is empty, which by default will be in no entity table. You decide for each element. To apply a stereotype the AI takes a baseline, applies the bare stereotype name with update_element AI Power Tools, then takes the census again to confirm the element is placed Engine. Declining is a valid answer; the AI then states what will be missing.
11. Run the reporting preflight, for a reporting database or Parquet files. (AI Power Tools, then you) build_reporting_database with the preflight only writes nothing and reports what the build would keep, cut and flag. A blocking defect is fixed in EA AI with computer use; otherwise you. You decide on each flag.
12. Build. (AI Power Tools, then AI) build_business_layer for views in the EA database; build_reporting_database for a reporting database or Parquet files. For a reporting database in Microsoft Fabric, the first operation in a server process that opens the database brings Microsoft's sign-in window to the front, and you sign in there You. The AI reads the timings aloud: they are the only sizing evidence for your repository.
13. Check. (AI Power Tools, then AI) check_business_layer, for both database ways, runs the alignment check and the value check. The AI reads the result. A Parquet build has no views to check; its build returns the same alignment summary.
14. Report. AI Four things, in this order: the delivery way and whether the data is live or a snapshot with its as-of time; whether the layer was checked, with the result; what is outside the layer (left-out packages, elements the inclusion choice left out, the "(excluded)" stand-ins, and every flag you continued past); and what was built (tables, row counts, the definition file and the timings). The third is never buried.
15. Keep it fresh. (AI Power Tools, driven by AI; then you) A scheduled AI agent starts a refresh with start_reporting_refresh, polls get_reporting_refresh, and reports. When the refresh raises drift flags, you rerun the inclusion choice.
16. Replay when a figure is disputed. AI Power Tools replay_reporting_database rebuilds a reporting database, or the Parquet rows, from the kept extract with no EA connection.
17. Remove when you are done. (AI, then AI Power Tools) The AI first tells you that a Power BI project built on the layer stops refreshing until the layer is rebuilt from the saved profile. remove_business_layer then drops the business views and their schema.

The three ways of delivering the data

Which way to use is a fact about your estate, not a preference. The AI asks three questions in order:

1. Can you reach the EA database directly, is it SQL Server, and may you create views in it? Then views in the EA database are available. The cost: the views live in the production database, and Power BI in DirectQuery queries that database.
2. If not, can you run a SQL Server, or do you have a Microsoft Fabric capacity for a SQL database in Fabric? Then a reporting database. EA's tables are copied into it, so queries never touch the production database.
3. If not, Parquet files. No database anywhere; Power BI Desktop imports the files.

Someone who could use views in the EA database may still choose another way, to keep views out of the production database or to keep the left-out packages away from Power BI. All three ways leave out the excluded packages.

What each way needs:

Use a schema of its own. Both database ways put the business views in a schema named in the profile (by default logical). A build drops every view already in that schema, and removal drops them all, so the schema must be dedicated to the business layer. Reserved schema names, including the database's default schema and the system schemas, are refused.

What each way produces:

Where the reporting database runs

A separate reporting database runs in one of two places, and the profile says which sign-in to use:

How the Microsoft Entra sign-in behaves.

• A person completes it. The first operation in a server process that opens the database brings Microsoft's sign-in window to the front. You sign in there, with multifactor approval if your organization asks for it. The profile can name the account the window suggests. The AI never signs in for you.
• Once per server process. Later operations in the same process reuse the sign-in. Measured: a build and two refreshes five minutes apart on one sign-in. A restart of the server, or an expired sign-in, shows the window again. How long a sign-in lasts was not measured.
• An unanswered sign-in stops the operation. After about ten minutes with no answer, the operation stops with a sign-in failure and writes nothing; a refresh leaves the previous data live. A canceled or failed sign-in is reported as a sign-in failure, not as a missing database.
• Someone has to be there. A scheduled refresh into a SQL database in Fabric needs a person at the machine when the server process first opens the database. There is no unattended sign-in.
• It needs the Microsoft OLE DB Driver for SQL Server on the machine where the server runs; version 18 was measured. Without the driver the operation is refused, and the message names Microsoft's download page.
• Only for a reporting database. Views in the EA database use Windows authentication only, and a profile that asks for Microsoft Entra sign-in for them is refused. A profile that names a sign-in account together with Windows authentication is refused too.

On the Westbrook Bank reference model, as an illustration only, a build into a SQL database in Fabric was aligned and its value check found no differences, the same result as the build into a local SQL Server. Power BI imports the business layer from it like any reporting database, and a model published to the Power BI service refreshes from it with no gateway (ea-power-bi).

The same rows on every way. For the same scope, the two database ways hold the same rows in every table, and the Parquet rows equal the views row for row. On the Westbrook Bank reference model, as an illustration only, the build produced 18 entity tables and 23 connector tables in under three seconds, and the value check found all 1,456 cells it compared equal to EA.

The reporting profile

Everything a build needs is in one saved file, the reporting profile, which you keep. Every build, check and refresh reuses it, so the answers you gave once are not asked again. It holds:

• the technology the layer follows;
• the scope: the root packages to include and the packages to leave out, both by GUID, so a renamed or moved package keeps its setting;
• the inclusion choice, and a record of it: which answer you gave, the gaps you excluded, and the technology version at the time. Without the record a refresh cannot tell an excluded gap from one that appeared since;
• where the output goes: the server, database and schema, and for a database the sign-in to use; or the folder.

Scope rules:

• There is no masking. Everything in a kept package is in the output, including notes and tagged values. To keep content out, leave its package out.
• Name every root package you do not want reported. A root package the profile names neither as included nor as left out is flagged on every run, because the flag exists for root packages created after the profile was saved and cannot tell those from ones you chose to leave out. Naming it in the exclusions records the decision.
• A profile entry that matches no package is flagged. A package deleted in EA is gone after the next build.

The inclusion choice

What the layer includes beyond the technology is your decision, made once, shown with counts, and saved in the profile. Nothing downstream second-guesses it. The AI puts all three answers, with their counts, every time a profile is created:

A stereotype counts as the technology's only when it is bound to the technology. The same name applied ad hoc, or bound to another language, is a gap, never the declared stereotype. Unstereotyped diagram furniture (notes, text, boundaries and package twins) is not model content and is neither counted nor offered.

Sending a gap to be declared is a hand-off, not an answer: ea-mdg-model-build declares it, the census is taken again, and the AI asks again. A profile is not produced while any gap is undecided or awaiting a declaration. Tables for what the technology does not declare carry names ending in "(not in MDG)".

Two data defects are not gaps, because they are mistakes in the repository and are fixed there: a connector whose stereotype is qualified text with no binding to the technology (for example a connector stereotype stored as WBA::Uses with no binding), which stops everything until fixed; and an element carrying two of the technology's stereotypes, which is flagged for you to decide.

The governance gate

An element with an empty stereotype lands in no entity table, unless you chose to include everything in the repository (which gives it a table keyed by its element type), so by default it is not in the layer. That is correct, because the tables are the business vocabulary and an element with no vocabulary term has no table to go in. It becomes a problem when the element carries governance data anyway. On the Westbrook Bank reference model three Components carried the complete tagged-value set (criticality Business-Critical, regulatory scope GLBA, owners, data classification) and no stereotype. Somebody classified them deliberately and no report would ever show them. The gate puts this in front of you before the build, not after.

Logic: rule-based. The gate lists the in-scope elements whose stereotype is empty, elements carrying governance tagged values first, because they are the ones that cost something. For each, it looks for the stereotypes the technology allows for that element type and weighs three signals:

1. The element type, as a hard filter. A stereotype that extends Component cannot be applied to a Node.
2. Package locality. Which stereotype do the element's stereotyped neighbors in the same package carry? This holds only where a repository is organized by type; a flat or domain-organized repository produces few votes, which correctly leads to "cannot rank".
3. Tagged-value fit. How well the element's tags match each candidate's declared tags. An element carrying only the common tags is not offered a stereotype that declares more it lacks.

A suggestion is made only when one candidate leads on both locality and tag fit. Package twins (the element EA keeps for every package so it can sit on a diagram) and diagram furniture are skipped.

Three outcomes, kept apart on purpose:

On the reference model, run over the Westbrook Bank package, 65 elements carry no stereotype: 3 carry governance tagged values, none gets a suggestion, 19 need you to choose, and 46 have no candidate (requirements and UML behavior elements, for which the technology declares nothing). Ten of the reference technology's fifteen element stereotypes declare an identical six-tag set, so tag fit alone cannot separate them; choosing the first alphabetically would be a guess wearing a number, so the gate refuses to rank. These figures illustrate the shape of a result and are not what to expect from your model.

Applying a stereotype. Take a baseline first (ea-change-management). The AI passes the bare stereotype name through update_element. With the technology loaded, EA resolves the name and records the binding to the technology itself. If the technology is not loaded, EA records an ad hoc application, which the census reports as drift and does not place in the technology's table. So the AI confirms the technology is loaded in this session, not merely present in the model (see ea-mdg-assess). update_element can report success together with a warning about the stereotype, and success does not mean the stereotype landed, so the AI takes the census again and confirms the element is placed.

If you decline, that is a valid answer, not an error. The AI says plainly which elements will not appear and carries on, for example: "Six elements will not appear in the reporting layer, three of which carry governance tagged values including one marked GLBA." It leaves diagram furniture out of that count, and the counts go into the report, so the layer can say later what was left out and that you were asked.

The reporting preflight

For a reporting database and for Parquet files, the reporting preflight is a run of the reading through EA and the package cut that writes nothing. It reports the rows that would be kept, the links that cross from kept content into a left-out package, the "(excluded)" stand-ins those links need, defects that block the build, and flags to show you before you continue. (It is a different check from the session preflight in ea-start-here.)

• Blocks the build: a connector whose stereotype is stored as qualified text with no binding to the technology. Fix it in EA after a baseline, by re-applying the stereotype from the technology's toolbox or through the connector's stereotype property, then run the reporting preflight again. Nothing is built while one remains.
• Flags, shown before you continue:
  • elements carrying two of the technology's stereotypes (each is then in both tables);
  • a root package created after the profile was saved, which is left out until you add it;
  • a profile entry that matches no package;
  • elements with two tagged values of the same name (the layer shows the first, as EA's Properties window does).
• Drift flags, from builds and refreshes, when the profile holds the inclusion-choice record: stereotypes and connector kinds that are in neither the technology, the included list nor the excluded list (for a gap-by-gap answer), and a technology version that differs from the one recorded. They are flagged, never decided.

Views in the EA database have no reporting preflight: the rights are checked first, and the census finds unbound connectors before a profile is written.

The business tables

Entity tables. One per element stereotype the inclusion choice admits, named by the stereotype's alias, or by its name where it has no alias (alias plus name where two stereotypes share an alias). Columns: the element's GUID, its name, its element type, its package path from the root, and one typed column per declared tagged value. Every entity table has the package path, so a report can slice by package even for a type with no tags. An element carrying two admitted stereotypes has a row in each table.

Connector tables. One per combination of source stereotype, connector stereotype and target stereotype that the technology allows, matching the technology's metamodel one for one, and named "Con_" followed by the source table, the connector stereotype and the target table (for example Con_Business Application Uses System of Record). The table exists even when nothing uses the combination. Columns: the connector's GUID and number, its name, the GUIDs of the elements at each end, its direction, its base type, and one column per connector tagged value. A connector joins its combination by its own binding to the technology plus the stereotypes at its two ends. A combination with the same entity type at both ends is a self-join, and a report must say which end it means.

Tables marked "(not in MDG)". Entity or connector tables for stereotypes or combinations the technology does not declare and the inclusion choice admits.

Tag-row tables (named after their table, followed by "tags"). One row per tag value, present only where a column cannot hold the data: tagged values the technology does not declare, and declared tagged values whose type is a list of referenced elements (one row per referenced element). Every other tagged value is a typed column, however sparsely it is filled. A checklist tag stays a column.

The Table Directory. One row per business table: its name and kind, its stereotype, alias and element type, the tables at each end for a connector table, whether the technology declares it, and the technology's description. A reader or an agent can find a table without knowing the technology.

EA's own tables, scoped. The nine EA tables the business layer reads: packages, elements, element tagged values, connectors, connector tagged values, diagrams, diagram placements, attributes and operations. They hold only what the scope includes, so a report can reach anything EA holds that a business table does not carry. A kept link into a left-out package ends at an "(excluded)" stand-in: a row that shows the element type and the name "(excluded)", never the real name.

Types and values, as EA shows them. A declared string, enumeration or date is text; a Boolean or integer is a whole number (a Boolean is 1 or 0); a decimal is a real number; anything else is text. Of two tagged values with the same name on one element, the first is used. A memo tagged value is read from its notes. Numbers are accepted in plain form only; a value that does not convert is empty on a typed column, and the value check reports it. An empty value is empty (NULL) on a number column and empty text on a text column, and EA writes NULL and empty text identically, so the two cannot be told apart. Dates read through EA in the machine's locale are stored in one standard form. Table names are limited to 123 characters; a longer name stops the build and lists the offenders.

Checking the layer: alignment and values

check_business_layer checks a built layer without changing it, for both database ways. It runs two checks.

• The alignment check measures the layer against the technology's metamodel, in counts: every allowed combination has a table; every bound connector whose two ends are placed lands in a combination; each connector table's row count equals the definition's own placement; and every element in two tables is listed. Every build also returns this alignment summary.
• The value check, on by default, compares every name, package path, tagged-value column, connector end, base type and connector tagged value with an independent read through EA, and reports the cells compared and the differences. EA must be open on the same repository the layer was built from. For a reporting database, edits made in EA since the build can show up as differences.

How to read the result:

• Aligned. If the only non-zero figure is the count of connectors outside every allowed combination, the build is correct: those connectors use a declared stereotype between two element stereotypes the technology does not allow together, so they stay in EA's tables and no business table shows them. The AI tells you each such combination and its count, and you either add the combination to the technology or treat the connectors as modeling errors and fix them in EA. A missing combination table, or a connector count that does not match, is a defect in the build: the AI stops and reports it.
• Values. Cells compared above zero and differences equal to zero. A check that compared nothing is a failure, never a pass.

The definition file

Every build writes a definition file beside the profile. It lists every table with its columns, declared types and row counts, plus the Table Directory and EA's own tables. The Power BI generator in ea-power-bi reads it, so it needs no database connection, and nothing downstream re-derives the shape.

The kept extract and replay

After every build of a reporting database or Parquet files, AI Power Tools keeps one file beside the profile, the kept extract. It holds the rows the build loaded, after the left-out packages were cut ("(excluded)" stand-ins included), together with the scope, the counts, the crossings, the flags you continued past, every query issued with its row count and timing, a run id and time, and the technology's definition.

• Only the last run is kept. Each build overwrites it. There is no history.
• Left-out content is never written to disk, at any stage. The cut is applied in memory before anything is written.
• It holds everything you chose to report, so treat it with the same care as the reporting data. Deleting it loses only the ability to replay.
• Views in the EA database have no kept extract: they read EA live.

Replay rebuilds the reporting database, or the rows for Parquet files, from the kept extract with no EA connection and no installed technology, because the technology's definition travels in the file. It reproduces that build's instant: use it to settle a disputed figure against the exact rows it came from, to retest a build, or to rebuild a lost reporting database without disturbing a shared repository. The result names the kept extract it used. A replay is not a refresh; to bring the data up to date, run a refresh. With no kept extract, the replay stops and names the missing file. For a worked replay see Rebuild a report without Enterprise Architect.

Keeping it fresh: the background refresh

A refresh runs in the background. One call, start_reporting_refresh, starts it and returns at once with a run id; a second, get_reporting_refresh, reports it as running, succeeded or failed, and when it has finished gives the row counts per table, every flag, the alignment summary, the timings, or the reason it stopped. It runs whichever delivery way the profile names:

A run that fails, or that the reporting preflight stops, leaves the previous data live and says why. One refresh of a profile runs at a time; asking for another while one runs returns the running one's id. Run ids are kept in memory until the AI Power Tools MCP Server for Sparx EA stops, so the server must stay up until the run ends.

A scheduled AI agent drives the refresh, in a session that has the server on the machine where EA runs. It starts the refresh, polls it, and reports the row counts, every flag, the timings and any failure. EA must be running with the repository open on that machine, or the refresh fails. The skill never uses Windows Task Scheduler for this. A refresh uses the saved inclusion choice and does not ask again, but it raises the drift flags described above; when they appear, you rerun the inclusion choice.

Removing the layer. remove_business_layer drops every view in the profile's schema, then the schema, and reports how many views it dropped. For views in the EA database, that removes everything AI Power Tools placed there. It never touches EA's tables or a reporting database's copied tables. A Power BI project built on the layer stops refreshing, in Power BI Desktop and in the Power BI service, until the layer is rebuilt from the saved profile: a build for views in the EA database, or a build or a replay for a reporting database. The AI says so before removing, so keep the profile.

Read-only mode refuses building and removing views, and refuses a refresh of views in the EA database, because those write into the EA repository's database. A reporting-database or Parquet build and a replay are allowed, because they write a separate database or files. See Reporting business layer.

Rules that are not obvious

• Join a connector to its ends by GUID. A connector table's source and target GUIDs are the GUIDs in the entity tables it names. A combination with the same entity type at both ends is a genuine self-join; name both sides.
• An element in two tables is counted twice by design, and so is a connector ending at it. Use the Table Directory and the alignment result to see which elements these are.
• A comma-joined text tag is one value in its column. GLBA, FFIEC is a single string: test it with "contains", not "equals", and say so when a roll-up depends on it. Only a tag declared as a list of referenced elements is split into rows.
• A sparse tag is still a column. A declared tag is a typed column however few elements fill it, so state the populated count with every figure.
• A blank is a blank. NULL and empty text cannot be told apart.
• A read that fails is an error. An unreadable result from EA fails the operation; it is never turned into "no rows".

Questions the business layer answers

The table names are the reference technology's and are illustrations; yours follow your technology's aliases.

Where the AI decides and where AI Power Tools decides

What you get

• The business layer, delivered the way you chose: views in the EA database, a separate reporting database, or the rows for Parquet files (the files themselves are written by ea-power-bi).
• The reporting profile, holding your scope and inclusion choice, reused by every build and refresh.
• The definition file beside the profile and, for a reporting database or Parquet files, the kept extract.
• The check result: aligned or not, and cells compared with the differences.
• A report in four parts: the delivery way and whether the data is live or a snapshot with its as-of time; whether it was checked; what is outside the layer; and what was built, with row counts and timings.
• On a schedule, a refresh report from the AI agent that runs it.
• To read the output in a Claude Cowork cloud session, connect the folder that holds the Parquet files, the profile and the definition file, never the folder that holds the model. A cloud session reads those files but cannot change the model (Security and data handling).

Tools it relies on

• The seven business-layer operations: Reporting business layer, with the engine behind them in Reporting business layer
• The technology definition: get_mdg_from_runtime in Discovering technologies
• The scope and the census rows: execute_sql in Direct queries
• Applying a stereotype after the gate: update_element in Elements, behind a baseline from ea-change-management
• Confirming a technology is loaded, and the full drift picture: ea-mdg-assess
• The census, inclusion and governance-gate engines: Census, inclusion choice and governance gate. They need local code execution with Python's standard library only
• Computer use, to start EA, open the model, fix a blocking connector in EA's interface and clear a blocking dialog

Sample prompts

1. The core build: session preflight, technology, the three delivery ways, scope, census, inclusion choice, gate, build, check, report.

2. Stops at the inclusion choice and walks the gaps, each with its count and an example name.

3. The reporting preflight only: blocking defects with their fix, and each flag.

4. Runs the alignment and value checks and reads the result, including any connectors outside every allowed combination.

5. Replays the kept extract, states the as-of time, and counts again from the same rows.

6. Explains that a scheduled AI agent drives the background refresh, that EA must be running with the repository open on that machine, and what each report contains, including drift flags.

The model, package and stereotype names are illustrations. Replace them with your own technology.

Recommended models

Ratings are guidance based on the kind of reasoning the skill needs, not measured benchmarks. Most of the computing happens in the server and the engines, so this skill depends less on the model than skills that rely on AI judgment throughout.

Checking accuracy and completeness

1. The layer is aligned. Correct: every allowed combination has a table and no connector count mismatches. If only the count of connectors outside every allowed combination is non-zero, the build is correct and the AI has named each combination and its count. Red flag: a missing combination table or a count mismatch reported as a success.
2. The values match EA. Correct: cells compared above zero and differences equal to zero, checked with EA open on the same repository. Red flag: zero cells compared reported as "no differences".
3. Row counts per table agree with EA. Ask the AI to compare each entity table's count with the stereotype usage summary for the same technology-bound stereotype. The AI explains every gap (left-out packages, elements the inclusion choice left out, elements in two tables) before you find it.
4. Nothing outside the layer is hidden. The report names the left-out packages, the "(excluded)" stand-ins, the elements the inclusion choice and the gate left out, and every flag you continued past. Red flag: a table count you can compare with EA that the AI did not explain first.
5. Populated counts are stated. Every figure comes with how many elements fill the column behind it. A comma-joined text tag is tested with "contains", not "equals".
6. The as-of time is stated for every figure from a reporting database or Parquet files. A spot check in EA may be a few rows off on a shared repository; replay the kept extract to settle it.
7. The inclusion choice was yours. The transcript shows all three answers put to you with their counts, and your answer recorded in the profile. Red flag: a layer built with no inclusion choice asked.

Limitations

• SQL Server for views in the EA database, reached with Windows authentication of the account running the AI Power Tools MCP Server for Sparx EA only. No SQL logins.
• A SQL Server you run, or a SQL database in Microsoft Fabric, for a reporting database. Fabric needs a Microsoft Entra sign-in that a person completes, once per server process, so a scheduled refresh into it needs someone at the machine when the server first opens the database.
• A reporting database's rights are not checked up front. A build that lacks them fails partway; the previous data stays live.
• Snapshots, with no history, for a reporting database and Parquet files. Each build is a full rebuild, and only the last kept extract is kept.
• A scheduled AI agent drives the refresh, and EA must be running with the repository open on that machine.
• Exclusion is by whole package, with no masking. Notes and tagged values in a kept package are all in the output.
• A comma-joined text tag is one value. Only a tag declared as a list of referenced elements is split into rows, and a checklist tag stays a column.
• Each build reports its own timings, which are the only sizing evidence for your repository. The figures in this section come from one reference model.
• The kept extract holds the included content and needs the same care as the reporting data.
• A later spot-check in EA may differ by a few rows on a shared repository. Replay to compare a disputed figure with the build it came from.
• A call that seems to hang is usually a modal dialog in EA: with computer use the AI reads and dismisses it; without it, you screenshot it, paste it into the conversation, then dismiss it.

The engines behind this skill are described in Census, inclusion choice and governance gate, and the build in Reporting business layer.