Every CleenUI-specific term used on the site, in the codebase, and in conversation with the architect — defined in one place with cross-references that resolve in-page. Read it top-to-bottom or jump directly to a term you saw on another page.
Words you'll hear an architect use when describing how CleenUI is put together.
The data-access layer CleenUI uses. Dapper is the lightweight POCO-mapper that turns ADO.NET DataReader rows into typed objects without the ORM machinery. Every database call in the codebase looks like 'open connection → execute stored procedure → Dapper-map results to POCO'.
Direct method calls between CleenUI modules — no network hop, no serialization, no service mesh. The trade-off vs. microservices: faster but only horizontally scalable to the limits of one deployment. CleenUI's modular monolith leans into this for the sync hot path; async work uses queues.
A horizontal tier of the codebase: L1 Frontend (React), L2 API (ASP.NET Core 8 Web API), L3 Database (Azure SQL), L4 Services (Azure WebJobs + Functions). Used in the Codebase tour to describe the stack as a four-layer cake. Distinct from a 'module', which is a vertical slice through all four layers.
A deployment style: a single deployable application (the monolith) internally organized into well-bounded modules with explicit in-process interfaces. CleenUI's modular monolith ships as one ASP.NET Core 8 Web API with 14 modules; cross-module communication is in-process, and async patterns use the WebJobs + Functions queue layer.
A short identifier used throughout the documentation, navigation, and module-detail pages. M01 is Security, M02 is Accounts, …, M14 is Vendor Marketplace. The codes are referenced in every module's detail page and in the SubFooter sitemap.
An architecture where a single application instance serves multiple isolated customers (tenants). CleenUI uses an account → companies → users hierarchy: the Account row is the tenant, the row-level access control enforces isolation, and per-tenant cache keys keep caching isolated too.
CleenUI does not use Entity Framework Core. The codebase predates EF being a serious option for the workload, and the team made an explicit choice to not adopt it once it became viable. Data access is Dapper + ADO.NET against stored procedures. Schema changes are hand-written T-SQL migration files checked into the repo, not EF migrations.
Multi-tenant data isolation enforced at the stored-procedure layer: every queryable table has an account-scoping column, and the stored procedures filter by it before returning. The application role cannot execute ad-hoc SQL, so a forgotten WHERE clause in app code can't leak cross-tenant data.
A data-access pattern: every read and write goes through a hand-tuned stored procedure (700+ of them in CleenUI), executed via Dapper + ADO.NET. Migrations are scripted T-SQL files. There is no Entity Framework, no DbContext, no LINQ-to-SQL. The pattern serious high-throughput .NET shops settle on once an ORM-driven codebase hits scale.
One of the 14 self-contained functional units (M01-M14) that compose CleenUI. Each module owns its React UI, ASP.NET Core 8 Web API endpoints, Azure SQL tables + stored procedures, and any background services that support it — a complete vertical 'slice' through the stack rather than a horizontal layer.
The schema-level concepts that shape what's queryable and how it's localized.
A sibling table holding per-language overrides for every translatable column on an entity. For example, account.Country has account.CountryLanguage; assessment.Question has assessment.QuestionLanguage. There are hundreds of these — one per translatable entity. Queries join the sibling table on the user's display-language ID at read time.
Append-only history rows captured for every mutable entity. The pattern: on every write, the stored procedure also inserts a *History row capturing the before-state, the actor, and the timestamp. Used for compliance, debugging, and the 'who changed this?' UX everywhere in the app.
A CleenUI domain-specific compound entity — a structured piece of content composed of multiple sub-elements. Used in the content system as the unit of composition for shareable assemblies. Mentioned in the news, topic, and category modules where 'attach to concat' surfaces in the API.
CleenUI's approach to i18n: user-editable content translates automatically without code changes. The translation registry, per-entity sibling tables, and background dispatch jobs combine to make 'add a new language' a configuration row + a backfill job, not a code release.
Forty-plus reusable schema patterns that ship with CleenUI — soft-delete, audit history, translation siblings, lookup tables, versioning, etc. New modules pick up these primitives by following the schema conventions rather than reinventing them.
Records are marked as deleted with a flag (typically IsDeleted + DeletedDate + DeletedByUserID) rather than physically removed. Stored procedures filter out soft-deleted rows by default; admin-level procedures can include them. Combined with audit history, this gives a complete restore-and-trace story.
The runtime metadata store that drives CleenUI's i18n system. It lists every translatable table + column in the schema, tracks which strings have pending translations, dispatches them to the configured machine-translation provider, and caches results. Adding a new supported language is a configuration row, not a schema change.
Several CleenUI entities (agreements, AI prompts, notify templates, artifact templates) keep full version history with restore — they're not just soft-deleted, they're rolled back. Implemented via *History tables that snapshot the entire row on every change.
The functional terms used to talk about what's in the codebase and where it lives.
The tenant — the row every multi-tenant query keys off of. An Account has one or more Users, a Plan (subscription tier), one or more Payment Methods, and a set of Roles + Permissions scoped to it. Documented in module M02 (Accounts).
Three packaged Claude Code / Cursor / Windsurf agent skills that CleenUI ships: Setup (provisions a new project), Builder (scaffolds pages and components), Theme (customizes the look). Each skill is its own MCP-compatible tool. Documented at /ai-skills.
The async-work layer of CleenUI — Azure WebJobs (always-on workers) and Azure Functions (event-driven). The 12-project Visual Studio solution covers translation queues, media safety, video encoding, thumbnails, LLM dispatch, and per-module reminders. Documented at /background-processing.
The naming convention used for every background WebJob and Function in the CleenUI codebase — cleenAccountActivityJob, cleenTranslationDispatchJob, cleenLLMUsageMeterFunction, etc. Module-detail pages list the likely cleen* jobs per module, but the exact set in any installation depends on which workloads the customer has enabled.
A per-tenant configuration bundle — which features are enabled, what content set is exposed, which countries are served, which browsers are supported. Editions let CleenUI ship a customizable surface per customer without forking the codebase. Defined in module M14 (Vendor Marketplace).
Model Context Protocol — Anthropic's open standard for letting AI agents fetch context and call tools. CleenUI's MCP server exposes the component catalog, module surfaces, and the AI skills (Setup, Builder, Theme) as a single integration point for any MCP-aware agent (Claude Code, Cursor, Windsurf, GitHub Copilot, etc.).
The 15 pre-built page structures the Builder skill scaffolds — Analytics, Dashboard, Datagrid, Email Engine, Settings, Wizard, Detail Screen, etc. Each template documents the components it uses, the structure of its sections, and the substitutions the agent fills in.
A UI-organizing grouping of related permissions — 'User management', 'Billing', 'Reports' — so the role-editor screen reads cleanly. The grouping is metadata; permissions themselves are the atomic capability check.
A subscription tier definition — Starter, Pro, Enterprise, or any other named offering. Plans bind to payment methods via the PaymentMethodVendorPlanMapping table (which maps internal plan IDs to vendor-specific identifiers like Stripe price_xxx).
Azure Storage Queues + Azure Service Bus, depending on the workload. Service Bus is used for high-priority + ordered delivery (notification fan-out, billing webhooks). Storage Queues handle bulk best-effort work (media processing, translation backfill).
Authorization model used throughout CleenUI: users are assigned to roles within an account; roles are granted permissions; controllers check permission bindings before letting work through. Combined with row-level access control, RBAC gives the 'who can do what to which rows' story.
How CleenUI gets from licensed to live in your team.
CleenUI's engagement model: the architect (Shawn Livermore) is the named delivery contact and stays involved from the 30-minute architecture review through go-live. Not a self-serve license, not a managed SaaS — a high-touch, custom-scoped engagement where the codebase ships alongside the architectural judgment that produced it.
The no-cost 30-minute kickoff call every CleenUI engagement starts with. Outcome of the call is a candid 'is CleenUI the right fit for this' answer plus, if it is, a custom scope. Book at /book-call.
CleenUI's pricing model — every engagement is priced against its actual scope (team size, modules in use, integrations needed, timeline). No fixed-tier license. The price-discovery happens during the architecture review.
The point at which a CleenUI installation moves from staging to production traffic. The architect is involved through go-live; what happens after that depends on the engagement contract (some customers retain ongoing architectural advisory, some take the codebase fully internal).
The thing you receive when you buy CleenUI: a private Git mirror of the full codebase — React frontend, ASP.NET Core 8 API, Azure SQL schema + stored procedures, Azure WebJobs + Functions. The license is one-time, not subscription. Once licensed, the source is yours forever.
Two paths to your first component. Pick the one that fits how your team builds.
One prompt to your AI tool. The Setup skill handles dependencies, design tokens, build config, and component registration — all without leaving your editor.
The classic flow. Install the package, import the styles, drop in your first component. No agents required — same end result.