Glossary

These are the product names shown in the app and on invoices — Nexus (Enterprise Intelligence), Forge (Solution Architecture), Loom (Service Design), Catalyst (Business Engagement) and Canvas (standalone diagramming). Under the hood each corresponds to a module key used in Settings, licensing and the API: ea, sa, sd, be and draw respectively. A workspace's edition is whichever combination of these modules is entitled — "Suite" means all four of Nexus/Forge/Loom/Catalyst; Canvas is a separate add-on not included by default even on Suite.

A Workspace is your tenant — the account every user belongs to and almost all data is scoped to. An Edition (Nexus-only, Suite, Suite + Canvas, etc.) is which *modules* your workspace can see, derived from enabled_modules. A Plan or Tier (Free/Pro/Enterprise) is a separate axis entirely: which *capabilities* are unlocked — SSO, custom roles, connectors, AI drafting, SCIM, SIEM streaming, IP allowlisting — independent of which modules you have. A workspace can, for example, run the full Suite on the Free tier (no SSO) or run Nexus-only on Enterprise (SSO, but no Forge/Loom/Catalyst screens to see).

Service (Service Design → Services) is customer-facing: what a service *does* for a customer, with a name, an owner and a lifecycle status. Architectural Service (Solution Architecture → Service Architecture) is technical/SOA: how a service is *built and run* — service type (API, event-driven, batch, shared library, data service), criticality tier, SLA target and team owner. The two are deliberately separate catalogs with no automatic link between them; if you're looking for a technical service contract and only find customer-facing Services, check whether Solution Architecture (Forge) is enabled for your workspace.

Several entities — most notably Service Design's Service — carry two independent status fields at once. The lifecycle status (proposed/active/deprecated/retired) is day-to-day operational state, set directly by an editor. The approval status is a separate governance field, only changed by going through a Review Request or Approval Chain, and it governs the whole record (including data that has no lifecycle status of its own). A service can be "active" and still sitting in a pending approval review — the two fields don't move together.

These sound similar but control different things. Module-gated means a whole feature is invisible unless your workspace's edition includes that module (require_module — a 402 if it's missing). Governed means a specific *record* moves through the Review Requests/Approval Chain workflow (draft → review → approved/rejected → superseded) regardless of which module it's in. Strategic Position Papers, for example, are explicitly *not* module-gated (their routes are ungated by design, just nav-hidden) but they absolutely are governed — publication is an approval step like any other governed record's.

A Strategic Position Paper moves through Framing (scope, assumptions, a capability-fit grid) → Positioning (the weighted Strategic Options Comparison, see below) → Transitioning (Work Packages and a Consultation Log) → in_review → published, the same draft-to-approved shape every governed record uses, just with EA-specific stage names. Publishing bumps the version number to the next whole integer (0.3 → 1.0) and locks the paper read-only; Supersede is the only way to revise a published paper afterward, and it creates a new linked draft rather than reopening the old one.

Both are weighted option-comparison tools, and both live in the Solution Architecture / Position Papers area, but they are two separate engines with separate tables. A Solution Design's decision matrix is part of the sa-gated Solution Architecture workflow. A Position Paper's Options Strategic Matrix (built during Positioning) is purpose-built specifically so Position Papers stay fully usable on a workspace where the sa module isn't entitled at all. Don't expect an option scored in one to show up in the other — they don't share data.

Inside a Solution Design, a Building Block is a logical piece of the solution (e.g. "Identity Service") that can optionally be *realised* by a real catalog object — an application, technology, data asset, or an Architectural Service — once it has an actual implementation. Components is the broader, looser link panel for any other catalog objects that make up the solution, each with an optional free-text role label, with no realization semantics attached.

Both are due-date-driven review mechanisms, but they answer different questions. A Recertification is an internal "is this record still accurate?" check — it shows up as overdue on the Dashboard/Mobile Summary and is cleared with a one-click "mark reviewed." A Survey is a tokenised, publicly-respondable questionnaire built on custom fields — you can send it to someone outside the app entirely (they don't need an Eidon account), and their response fills in the surveyed fields directly. A record can be on both a recertification schedule and a custom-field survey at the same time, independently of each other.

Every account has one of three base roles — Admin, Editor or Viewer — enforced identically in the UI and the API, on every workspace regardless of plan. On workspaces with the custom-roles feature entitled (Pro/Enterprise), admins can additionally define named custom roles with a fine-grained set of capability checkboxes layered on top of the base model. Custom roles narrow or widen what a specific named role can do; they don't replace the underlying Admin/Editor/Viewer distinction, which still governs baseline access like Settings visibility.

"Promote" shows up in several unrelated places and always means the same shape of action — turning a less-formal record into a more-formal, tracked one of a different type — but never the same two types twice: a Solution Design's recommended option promotes into a pending Architecture Decision; a published Position Paper's Work Packages promote into new Business Engagement demand-pipeline intake; a Business Engagement Engagement promotes onto the strategy Roadmap; a Rationalization classification promotes a TIME quadrant read into a tracked disposition decision. Each is a one-way action from its own source page — there's no single "Promotions" list to check them all in one place.