Inside the server

The server is built from the six tools and ping (see How tools and operations work), plus the 13 modules described here. The modules sit behind the operations. You never call a module directly, and an assistant cannot ask for one by name. A module shows up only through the behavior of the operations that use it: an error, the shape of a result, a file written, a limit.

Deterministic means that, given the same inputs and the same model state, the module produces the same result with no AI judgment involved. For a module that reads Enterprise Architect the model state is part of the input, so a changed model giving a different answer is still deterministic (Where the AI decides and where AI Power Tools decides). This section explains what each module does so that a result, an error or a limit in an operation can be traced to its cause. Each entry gives the module's job and why it matters to you, who decides (Deterministic or Rule-based, using the labels in Where the AI decides and where AI Power Tools decides), what goes in and comes out, what uses it, and where it stops.

Connection manager

Module: connection. Logic: Deterministic.

What it does and why it matters. It attaches the server to a running Enterprise Architect and gives every operation access to the open repository. Every operation that touches the model reaches EA through it. It keeps its connection to EA for as long as the server runs. It holds one connection per thread, so a reporting refresh running in the background (Reporting business layer) reaches the same EA through its own connection while you keep working.

Takes in and produces. Takes an optional project path. Produces a live connection to the repository, or one of two clear conditions: EA is not running, or EA is running with no model open. The server turns these into the messages you see, each naming the operation that fixes it (launch_ea; open_model or create_model). The message states the fact and stops there. Deciding whether to start an application on your machine is the assistant's job, after it asks you.

How it behaves.

• It attaches; it does not start EA. It reuses its connection if EA still answers, otherwise attaches to a running instance, otherwise reports that EA is not running. The server starts EA only through launch_ea, which the assistant calls after you agree. With computer use the assistant can also start EA through the desktop, after asking.
• It checks the connection before trusting it. If the saved connection no longer answers (EA was restarted), it drops it and reconnects.
• A model must be open for any operation that works on the model. Operations that act on the application itself (opening or creating a model) skip that requirement.
• Opening a project compares the path with the current one, ignoring case, and opens the file only if they differ. create_model appends .qea if the path does not end in it, creates the model and then opens it.

Used by. All of ea_model, ea_diagram, ea_analyze and the rest. launch_ea, open_model, create_model and open_project in ea_repository drive it directly.

Limitations.

• Windows only, and EA must be installed on the same machine. See Limitations and known issues.
• One EA instance per seat. Never start a second instance against the same model file.
• When EA shows a dialog, calls block until it is dismissed, and the module cannot detect this. If a call appears to hang, with computer use the assistant reads the dialog, corrects the call, dismisses the dialog and keeps going. Without computer use, you paste a screenshot of the dialog into the conversation and then dismiss it (Blocking dialogs in How tools and operations work).
• After EA restarts, any object a script held across the restart is no longer valid. This matters to ea-com scripts, not to the server.

SQL guard

Module: sql_validator. Logic: Rule-based. It is repeatable, and it can be wrong in both directions: it can miss an invalid column, and it can reject a valid one.

What it does and why it matters. It is the query safety check that runs before a direct query reaches EA. EA's table and column names are inconsistent (some tables name a column in the singular, others in upper case), so a guessed column name sends a query that fails inside EA, and a statement EA cannot parse can raise a dialog that blocks the session. The guard catches the mistake first and suggests the real name.

Takes in and produces. Takes the text of the query. Produces nothing if it looks fine, otherwise an invalid-column message listing each problem with up to three close column names on the same table, plus a note such as "column exists on another table" when the name is real elsewhere.

How it behaves.

1. It finds the EA tables the query names. Only tables in the schema catalog count. A table the catalog does not know is ignored, and if none remain the query passes unchecked.
2. It checks columns that name their table (alias.Column) against that table.
3. It checks bare column names only when the query touches exactly one known table. With several, it cannot tell which table a bare name belongs to and leaves them alone.
4. It ignores what is not a column: text in quotes, SQL keywords, function names, table names and aliases, and result aliases.
5. It flags a leftover bare name when it starts with a capital letter, closely resembles a real column, or is a real column on a different table.

Used by. execute_sql only (see Direct queries). Queries that the server issues itself do not pass through it. The assistant can switch the check off for a single call. That never bypasses the rules about writing.

Limitations.

• Unknown or misspelled tables are not checked, so such a query passes the guard. A server connection or cloud connection that cannot run the statement may raise a blocking dialog in EA.
• Multi-table queries are checked only on columns that name their table.
• The catalog comes from a SQL Server schema. A .qea is SQLite, so a column can be in the catalog and absent from a particular model, or the reverse. The guard checks names, not types or dialect.

Schema catalog

Module: schema. Logic: Deterministic.

What it does and why it matters. A built-in reference of EA's repository tables, so the assistant can look up a column instead of guessing. It was generated from Sparx's own schema script (schema version 1558) and is not edited by hand. It holds 98 tables, each with its key column, its columns and their types, the columns that need special quoting because they are reserved words, and short notes on the table's quirks. It also keeps an index from column name to the tables that hold it, which the SQL guard uses to say "this column exists on another table".

Takes in and produces. Takes no input. It feeds describe_table and list_ea_tables (see Direct queries) and the SQL guard. An unknown table name returns up to five suggestions.

Used by. describe_table, list_ea_tables, the SQL guard.

Limitations. The catalog describes the schema as of one EA build. A table or column added by a later build is unknown to it. Column types are SQL Server types and do not describe how a .qea (SQLite) or .eap (Jet) file stores the value.

Serializer

Module: serialize. Logic: Deterministic.

What it does and why it matters. It turns EA's packages, elements, connectors, diagrams, attributes, operations and tagged values into the plain descriptions you see in results. It defines which facts come back for each kind of object. For packages, elements, connectors and diagrams there is a full description and a minimal one (identity only). Operations that change or list things return the minimal form unless you ask for detail, which keeps responses small.

Takes in and produces. Takes an object read from EA. Produces its description.

How it behaves.

• A missing property never fails a whole result. EA raises an error when asked for a property that does not exist for a given element subtype. The module substitutes an empty value, so one gap does not spoil the rest of the answer.
• A collection that cannot be read reads as empty, not as an error.
• The stereotype shown prefers the language-qualified name, falling back to the plain name.
• Dates come back as text.

Used by. Nearly every operation in ea_model and ea_diagram that returns an object, and the Visio writer (Visio writer), which uses it to read a diagram's placed elements and links.

Limitations. A property EA refuses to return appears as empty, which is indistinguishable from a property that really is empty. When a result looks incomplete, confirm with a direct query (Direct queries) or verify_diagram (Verifying a diagram).

Live MDG reader

Module: mdg_live. Logic: Deterministic. It locates and reads technology files. It does not interpret them.

What it does and why it matters. EA's automation interface can say whether a technology is loaded and what version, and nothing more. It cannot return a technology's stereotypes, tagged values or diagram types. This module finds the technology file EA actually loaded, so the server can answer from the real definition instead of a table of its own. It is the reason get_mdg_from_runtime can be trusted.

EA keeps that file in three places, and the module reads all of them: a registered technology file (in the per-user folder, in any configured search path, and in EA's own install folder), a technology stored in the open model at Location: Project, and a technology stored in the open model at Location: Model.

Takes in and produces. Takes a technology id. Produces the technology's file content, which the server then reads with its own parser, together with where it came from and any other copy of the same id the model holds.

How it behaves.

• Folder order matters. The per-user folder comes first, then configured search paths, then EA's install folder. A file in the per-user folder shadows the copy in the install. This is the same shadowing that makes an author's workstation disagree with everyone else's.
• The first match for an id wins. If two files declare the same id, the earlier folder's file is used.
• A registered file beats the model's copies, because that is what EA loads.
• Location: Project beats Location: Model. With the same id stored at both, EA answers from the Project copy, and so does the module. The copy that lost is reported as also stored, with the version it declares.
• A Location: Project copy is reported only if it carries at least one profile. A technology entry with no profile defines no stereotypes, and answering from it would be a fabrication.
• A Location: Model copy is read whole. EA stores it as one compressed copy of the complete technology file. A copy that cannot be decoded, or that expands to more than 64 MB, is reported as unreadable with the reason, never skipped silently.
• It finds EA's install folder from the Windows settings. If that cannot be found, the install folder is skipped.

Used by. get_mdg_from_runtime (Discovering technologies) and the other discovery operations that report what the model stores; install_mdg, which reads back what it stored; the language-aware creation operations such as create_element_in_language and create_diagram_in_language, which resolve a language through this module before falling back to a built-in table; the reporting operations (Reporting business layer), which read the technology's definition the same way; and the icon library reader (Icon library reader), which uses its lookup of EA's install folder.

Limitations.

• It cannot list technologies EA has loaded from files. It looks up an id you already have, and it can list only what the open model stores. This is why list_available_modeling_languages works from known ids.
• A cloud-hosted technology is not reachable (reported, not independently verified).
• It reads definitions; it does not prove EA is using them. Installed, embedded, registered and loaded are different states, and a loaded technology can still be disabled; see Technology states and ea-mdg-assess.

Validation engine

Module: validate_model, a function in the server itself. Logic: Deterministic. The same rules and the same model give the same violations. The rules themselves are written by a person or by ea-ruleset-author.

What it does and why it matters. It is the evaluator behind audit in ea_validate. It reads a ruleset, queries the open model and returns the violations. It only reads the model.

Takes in and produces. Takes the ruleset (a path, an https:// address, or the text), the mode and an optional package scope. Produces the violation list, or an error that points at the problem with the ruleset. The kinds of rule it evaluates, the order in which the ruleset argument is resolved, and the limits that apply are described in ea_validate. This section adds the points that follow from how it is built.

How it behaves.

• The ruleset is read as safe YAML. Rule shapes are validated before any rule runs, so a malformed ruleset fails at once and names the offending rule.
• Element rules find candidates by exact stereotype as stored, optionally limited to a package subtree and a tag filter, then read each candidate's tagged values by tag name.
• Connector rules report the connector's id and a name of the form connector#<id>.
• A rule that checks tagged value types shipped compares the types defined in the model's reference data with those in the built technology file, which can be a path or the file's text.

Used by. audit, and through it ea-validation and ea-ruleset-author.

Limitations.

• Unrecognized rule parts are skipped silently, and still count as evaluated. Confirm a new rule by making it fail on a known bad element.
• Package scope applies to element rules only. Connector rules scan the whole model.
• One query per candidate and tag. A broad ruleset over a large population issues many small queries. Scope with the package option.
• Only the rule kinds listed in ea_validate exist.

Visio writer

Module: vsdx. Logic: Deterministic.

What it does and why it matters. It builds a Visio .vsdx file from an EA diagram, without Visio installed. It is the engine behind export_diagram_to_visio in Exporting.

Takes in and produces. Takes a diagram (read live from EA) and a scale in pixels per inch (96 by default). Produces the .vsdx file and counts of shapes and connectors with the page size.

How it behaves.

• One shape per placed element, a rectangle whose text is the stereotype in guillemets and then the element name, one per line.
• One connector per link, a straight line between the two shapes' centers, with the connector name as its text. A connector is written only when both of its ends are placed on the diagram. Otherwise it is dropped and not counted.
• EA's top-left origin is converted to Visio's bottom-left, and the page is sized to fit the diagram plus a half-inch margin (letter size for an empty diagram).

Used by. export_diagram_to_visio; see ea-import-export.

Limitations.

• A plain rectangle per element. No per-type stencil shapes, no BPMN or swimlane shapes, no bend points. Connectors are straight and are not glued to the shapes, so moving a shape in Visio does not move its connector.
• Element appearance (colors, fonts) is not carried over.
• The file contains one page.

Updater

Module: updater. Logic: Deterministic.

What it does and why it matters. A background check that tells you when a newer server version is published. It never downloads or installs anything, and the only outbound request it makes is the version check. There is no telemetry.

Takes in and produces. No input from you. The result is read through two operations in ea_repository: check_for_updates, which says "checking" while the first check is in flight, "current", or describes the newer version (with release link, how AI Power Tools was installed on this machine, and the upgrade steps for that installation); and get_repository_info, which adds an update block when a newer version exists. Forcing a check starts a fresh one; the call still returns at once and the new result appears on the next call.

How it behaves.

• It runs once at server start on a background thread, so startup is never delayed. A later start-up check is skipped if the stored result is under 24 hours old.
• By default it reads the public AI Power Tools release feed. An administrator can point it at another source.
• A network failure leaves the last result in place. If the first check fails, the answer stays "checking".
• The request carries only the server version.
• It names the installation and gives the steps for it. It works out how AI Power Tools was installed from where the server runs on disk: the Claude Desktop extension, the VS Code extension, or a plugin package left by an older release. The notice names that installation and gives its upgrade steps, which are summarized in Project and described fully in Updating and uninstalling. For a server that arrived inside a plugin package, the notice says the plugin carries only the skills, gives the steps to install the Claude Desktop extension, and gives the marketplace sync steps for the skills. Only the Claude Desktop extension's notice carries the warning to disable the extension before updating.

Used by. check_for_updates and get_repository_info.

Limitations.

• A plugin file uploaded in Claude Desktop does not update itself. The notice tells you a newer version exists and that you upload the newer plugin file.
• If the server cannot work out how it was installed, it gives neutral guidance: download the release, install it the way you installed this one, and restart the application that runs the server.
• The check runs at start and on demand. There is no timer inside a long-lived session.
• This check reports a newer server. Skills are compared through ping, which takes the skills' release from the ea-start-here preflight (The AI Power Tools MCP Server for Sparx EA).

Diagnostics

Module: diagnostics. Logic: Deterministic.

What it does and why it matters. An opt-in recorder that writes a Markdown issue report when a tool call fails or runs slowly, so you can send support one self-contained file. It is separate from the ea-diagnostic skill, which produces a written report from the session. The module records automatically. The skill is the AI's own write-up.

Takes in and produces. It wraps every call to the six tools (not ping), adding timing and outcome capture. It writes a report only when diagnostics is on and a problem is detected. Reports are named for the time and the tool.

Settings. Diagnostics is off by default. The Claude Desktop extension offers five settings on its Configure screen; three of them are for diagnostics: enable diagnostics, the diagnostics folder and the diagnostics timeout. The VS Code extension offers eaMcp.diagnostics and eaMcp.diagnosticsDir (see Settings). Behind them are three environment variables: EA_MCP_DIAGNOSTICS (on or off), EA_MCP_DIAGNOSTICS_DIR (default %LOCALAPPDATA%\ea-mcp-server\diagnostics) and EA_MCP_DIAGNOSTICS_TIMEOUT (seconds before a call counts as slow, default 30). get_repository_info shows the settings in effect.

Log level. The server's log level comes from EA_MCP_LOG_LEVEL. The VS Code extension sets it through the setting eaMcp.logLevel (DEBUG, INFO, WARNING or ERROR; the default is INFO). The Claude Desktop extension sets it through Log level on its Configure screen (default INFO). The plugin carries no server.

What triggers a report. A call that raised an exception; a call that returned an error; a call that took at least the slow-call threshold. A successful, fast call writes nothing.

What a report contains.

1. A header asking you to email the file to help@novocircle.com and to review it first, because it can hold model names, package paths, element identifiers and free text from the repository.
2. A failure summary: tool, outcome, detail, start time, duration.
3. The environment: server version, operating system, EA version, repository type and project path (EA details are best effort).
4. The tool call: its arguments and result. Any text longer than 500 characters is cut.
5. A stack trace, for an exception.
6. Recent activity: the last 25 calls with time, tool, duration and outcome.
7. Server uptime and counts.

The result of the failed call also gains the report's file path and a support message, so the assistant can show you where the file is.

The recent-activity memory is always on. Even with diagnostics off, the last 25 calls are kept in memory so a report can include them if one is written. Nothing is written to disk and nothing leaves the process.

Limitations.

• Reports are written on the machine that runs the server. Sending one is your action.
• Only text over 500 characters is cut. Shorter element names and notes appear verbatim, so review the file before sending.
• A failure inside EA that does not surface as an error, such as a blocking dialog, cannot trigger a report until the call returns. A call that never returns writes nothing.

Skills installer

Module: skills_installer. Logic: Deterministic.

What it does and why it matters. The older way to deliver skills: it downloads the skill bundle from the public skills repository's latest release and copies it into ~/.claude/skills. The plugin is the supported channel (see Claude plugin). This module declines to install when the plugin already supplies the skills, because a machine carrying both loads every skill twice. It remains because customers who installed the older way still have records on disk, and the pruning and conflict operations act on them. The operations that front it are in Skills (legacy).

Takes in and produces. Takes the names of skills, a force option, and a target folder. Produces a report of what was copied, skipped as unchanged, skipped as locally edited, skipped as incompatible, or failed, and whether the install is complete. Read the "complete" answer, not just "ok": "ok" says the call ran, and "complete" is false whenever a requested file is not now in place.

How it behaves.

• Where files go. Every named target resolves to ~/.claude/skills; they are kept so saved scripts work. Rulesets go under ~/.claude/ai-power-tools/rulesets, never among the skills.
• Every file is verified. The release carries a manifest with a checksum for each file. Each downloaded file is hashed and compared; a mismatch is reported and the file is not written.
• Version floor. The bundle's minimum server version is enforced as all or nothing. A server that is too old writes nothing, because half a bundle would be skill text describing operations the server lacks.
• Your edits are protected. The install keeps a record of what it wrote. A file that matches the release is skipped. One that differs from the release but matches the record is ours and is replaced as an upgrade. One that differs from both looks locally edited, is left alone and is reported. That is a suspicion, not a finding: you can force the overwrite, or compare file by file and choose to keep yours, use the server's, or use a merge. Overwritten files are backed up first.
• Standing down for the plugin. If the server runs from a plugin package left by an older release, a request to install into the real skills folder is declined and points to the plugin update. A force option overrides it. A different target is never refused.
• Pruning. The prune operation is a dry run unless you apply it. It removes only directories whose ownership is proven: the name is on a fixed list of renamed or withdrawn skills, or the install record names it. A skill of your own whose name starts with ea- is never touched. Files that differ from the record are backed up first. Installing never prunes; it only reports legacy installs it detected.
• Paths are checked. A relative path from the release or from a request is rejected, not cleaned up, if it is absolute, names a drive, contains .., or resolves outside the target folder.
• Background check. At start, a background thread fetches the manifest and sorts each file into needs update, in conflict, or not installed. The cached result appears as a skills-update block in get_repository_info. It is rechecked at most once in 24 hours. When the server is the Claude Desktop extension, the check fetches nothing: the skills come from the plugin on the claude.ai account, so the block never recommends install_skills. It lists any copies the older installer left, with the steps to add the plugin and remove them, or gives one pointer to the plugin on the claude.ai account, or is absent once the assistant's ping has reported a skills release.
• The check stands down for the plugin. When the plugin supplies the skills, the background check fetches nothing and reports no updates. It reports only skill copies the older installer left in the skills folder, taken from the installer's own record and never from a listing of the folder, so your own skills and those of other products are never named. Those copies load a second time beside the plugin's, and the remedy it names is the migration script migrate-to-plugin.ps1, run first with its what-if option (Moving from an older installation). With no leftovers, the skills-update block is absent.

Used by. list_available_skills, install_skills, prune_legacy_skills, get_skill_update_diff, resolve_skill_conflict, and the skills-update block in get_repository_info.

Limitations.

• Not the supported channel. New installs use the plugin. The module and its five operations are kept for customers who still have an install record.
• It does not check plugin-delivered skills for updates. Plugin skills update with the plugin; see Updating and uninstalling. The migration script, not this module, removes the leftover copies. It also finds installs made before version 2.2.0, whose record sits inside the skills folder.
• A server skips skills released after it, by its version floor.
• GitHub must be reachable to list, install or check. There is no offline source.

Demo languages

Module: demo_languages. Logic: Deterministic.

What it does and why it matters. A small opt-in module that holds the definition of WBA, the fictitious Westbrook Bank Architecture language used in AI Power Tools' own tests, demonstrations and documentation. It exists so that no customer's language list advertises a made-up technology as installed. Westbrook Bank is not a customer, and none of the module's data is customer data.

Takes in and produces. It reads one setting, EA_MCP_DEMO_LANGUAGES. When it is on, the module adds WBA and WestbrookBankArchitecture to the language lists (stereotype definitions, display aliases and tag aliases) and lists them as user-installed technologies. Both ids are accepted because EA registers WBA while people see WestbrookBankArchitecture. When it is off, which is the default, it contributes nothing, and the identifiers disappear from every language operation at once.

Used by. The language operations in ea_mdg, such as list_available_modeling_languages, assess_mdg_situation and resolve_display_term, and the language-aware creation operations. A real technology with the same id always wins over the demonstration one.

Limitations.

• The built-in demonstration definitions cover 7 of the reference technology's 14 stereotypes and carry no tagged-value definitions or diagram types. One base element type differs from the technology's, and one stereotype is ad hoc rather than part of the technology. The live MDG reader (Live MDG reader), which reads the real file, is the authoritative source.
• A customer never needs this module. The Westbrook model is AI Power Tools' internal fixture and is not shipped. Treat every Westbrook value in this reference as an illustration to replace with your own technology.

Icon library reader

Module: icon_libraries. Logic: Deterministic for indexing and extraction; rule-based for search ranking.

What it does and why it matters. It is the module behind find_icon and set_element_icon in Vendor icon libraries. EA installs AWS, Azure, Google and data-platform icon sets as model pattern files in its own install folder (thirteen files and about 5,200 icons in the EA build the server was checked against). The module reads those files in place from your own install. Nothing is downloaded and no artwork ships with AI Power Tools.

Importing one of those files into a model does not make its icons usable as element images, because EA stores the pictures where an image placement cannot find them. The server therefore extracts the picture and adds it to the model as an image.

Takes in and produces. A search takes a query, an optional provider and a limit, and returns matching icons best first, each with how it matched. Extraction takes an icon id and returns the picture. The index holds names and ids only, never image data.

How it behaves.

• Where the libraries are. An administrator setting (EA_MODEL_PATTERNS) if present, otherwise EA's ModelPatterns folder. A library is any file in that folder whose name contains "images" and that ends in .xml. If none is found, the operations say so and tell you to set the folder and restart the server.
• Provider and vintage come from the file name: AWS, Azure, Google, "Data platform", or "Other"; and a vintage taken from the name suffix, or "base". Newer vintages rank first within a provider. A file the server does not recognize ranks after every known one: an unknown vintage is treated as oldest, never as an error.
• The index is cached, in memory and on disk, and rebuilt when a library file changes, such as after an EA upgrade. The first load takes about two seconds. A corrupt or unwritable cache costs a re-read, never a wrong answer.
• Search ranking (rule-based). Best first: an exact match ignoring case, a match ignoring punctuation, vendor words (Amazon, AWS, Azure, Microsoft, Google, Cloud) and a trailing plural, a match containing every word of the query, then partial matches. Within a kind the newest vintage comes first. So storage ranks a literal "Storage" icon above "Cloud Storage". The provider filter ignores case.
• Image names are kept unique. Artwork is stored under <provider> <vintage> - <name>. When icons within a library share a name but look different, each gets the first eight characters of its identifier appended. Same-named icons with identical pictures share one plain name. A picture that cannot be decoded counts as different, so the rule errs toward adding a suffix.
• An id cannot name a file. An icon id resolves only against the index built from the folder's own files.
• A picture is read up to 1 MB. Each icon's picture is read only up to 1 MB, the same limit add_image applies, whatever size the library file declares for it. A larger one is reported as unreadable.

Used by. find_icon (search) and set_element_icon (extract and place), both in ea_diagram.

Limitations.

• It needs an EA install with the shipped libraries, or a folder that has them. Other icon sets are not read.
• Adding a new icon image needs a local file (.qea or .qeax). Reusing an image already in the model works with a server connection or a cloud connection.
• A successful set_element_icon means the image and its placement were read back. It does not mean EA drew the picture. Render the diagram with verify_diagram to check.

Reporting business layer

Module: reporting. Logic: Deterministic. The same technology, profile and repository give the same tables and the same rows on every delivery.

What it does and why it matters. It turns a technology's metamodel, your reporting profile and the repository's content into one definition of the business tables, and then delivers that one definition three ways: as SQL Server views over EA's tables (direct access), as a separate reporting database, on SQL Server or in a SQL database in Microsoft Fabric, with the views over a copy of EA's tables, or as rows for Parquet files. Because every delivery comes from the same definition, a report built on one works on another. It is the engine behind the seven operations in Reporting business layer.

Takes in and produces. Takes the technology's definition (read the same way as the live MDG reader, Live MDG reader), the saved profile, and the repository's tables, read either directly from the database or through EA. Produces the views, the loaded reporting database or the rows for Parquet, the definition file the Power BI generator reads, the kept extract, and the check results.

How it behaves.

• The metamodel decides the tables. One entity table per element stereotype the technology declares, named by its alias; one connector table per allowed combination of source, connector and target stereotype; tables marked "(not in MDG)" only for what you chose to include; tag-row tables only where a column cannot hold the data; and a Table Directory. An element carrying two included stereotypes is in both tables.
• The scope is cut by whole package. Packages are named by GUID. A link from kept content into a package left out is kept, and its far end becomes an "(excluded)" stand-in that shows the element type, never the name. A root package the profile does not name is left out and flagged.
• Reading through EA is checked. EA's tables are read in ranges, and each table's row count is compared with what was read; a mismatch stops the build. Dates, which EA formats for the machine's locale, are converted to one standard form.
• Writes are swapped in whole. The views are rebuilt inside one transaction in their own schema, and a reporting database is built in a staging area and swapped in inside one transaction, so a reader sees the old data or the new, never a mix. The views read EA's tables and never write one.
• Parquet rows reproduce the views. Without a database, the rows are computed from the kept extract by the same rules the views apply, so they hold the same rows as the views.
• Checks fail loudly. A check that read nothing it expected to read is reported as a failure, never as zero differences.
• The background refresh runs on its own thread with its own connection to EA (Connection manager), and its result is kept in memory until the server restarts.

Used by. The seven operations in Reporting business layer, and through them ea-reporting-database and ea-power-bi.

Limitations.

• SQL Server only for direct access, reached with the Windows account that runs AI Power Tools. A reporting database is on SQL Server, reached the same way, or in a SQL database in Microsoft Fabric, reached with Microsoft Entra sign-in: a person signs in at Microsoft's sign-in window once per server process, through the Microsoft OLE DB Driver for SQL Server, and an unanswered sign-in stops the operation after about ten minutes without writing anything. Writing the Parquet files themselves is a local step in ea-power-bi, not part of the server.
• No masking: exclusion is by whole package.
• Only a tagged value that lists referenced elements is split into a tag-row table. Other multi-value tagged values stay a single text value in their column.
• A reporting database and Parquet output are snapshots as of their last build. Only the last run's extract is kept, with no history.