Taxonomy UI production solution architecture — session record
Tag: S-2026-07-26-paul-taxonomy-ui-production-architecture Type: own-writing Author(s): Paul Miles / Claude (Cowork session) Date of source: 2026-07-26 Date ingested: 2026-07-26 Authority weight: high — first-party work record; external platform claims carry web sources in the architecture document itself. Raw file: /_raw_sources/S-2026-07-26-paul-taxonomy-ui-production-architecture.md
What it claims
A production solution architecture was produced for the CLM Taxonomy Dashboard UI, saved as CLM_Taxonomy_UI_Production_Solution_Architecture.md/.docx (plus an SVG/PNG architecture diagram) in _ClaudeWorkspace/09 Taxonomy Tool/. It converts the sold wireframe (v2, 440 terms) into the HLD v0.2’s D-7 “thin web portal”, scoped to a first client that runs Azure for its operational data store, Power BI heavily, Dynamics in the UI estate, React as UI standard, and Teams as the main user surface.
Paul took three shaping decisions in-session: deploy into the client’s Azure tenant via Bicep IaC; v1 scope is the read surface plus a real governed approval workflow (four-eyes, append-only audit) replacing the demo overlay; package for resale as a deployable application rather than a component library.
The architecture: one React 18/TypeScript/Fluent UI v9 codebase delivered as Teams tab (silent Entra SSO, primary), browser SPA (MSAL) and a thin Dynamics PCF wrapper; a single Node/TypeScript REST API (OpenAPI 3.1) on Azure Container Apps as the only path to the database, written so an MCP adapter can be added later; Azure Database for PostgreSQL Flexible Server holding the HLD’s relational core (terms, immutable versions, proposals, approvals, append-only change record) plus a curated read-only bi schema for the client’s own Power BI reporting; the existing Python validation pipeline productionised as a Container Apps Job reading the governed workbook from SharePoint via Graph and diffing to proposals. Authorisation uses Entra app roles (Reader/Steward/Owner/Risk/Admin) assigned through the client’s existing AD security groups, so joiner/mover/leaver, conditional access and access reviews stay in the client’s IAM estate; enforcement is server-side.
Resale channel order recommended: direct consulting-led sales now; AppSource Teams listing (non-transactable) after client 1; Azure Marketplace Azure Application offer (transactable, MACC-eligible) at scale; partner resale via Marketplace resale enablement. Build estimate 10–14 weeks for one senior full-stack engineer plus Paul.
Notable quotes
“The production build is therefore not a rewrite of the concept — it is a re-platforming.” (architecture document, §2)
What’s speculative vs. asserted
Asserted from primary sources: platform capabilities (Teams tab SSO pattern, PCF vs iframe auth-boundary limitation, pgvector 0.8.x GA on Azure Flexible Server, app-role portability, Marketplace/AppSource offer mechanics) — each carries a Microsoft Learn or vendor source link in the document’s §12. Asserted as decision: hosting, scope and packaging choices (Paul, 2026-07-26). Speculative/estimate: the 10–14-week build estimate and sprint plan; Marketplace channel sequencing is a recommendation, not a tested outcome.
Topics this feeds
- Taxonomy Knowledge Tool — this architecture is the delivery design for the HLD’s D-7 portal slice.
- CLM Data Taxonomy Governance — the reference engagement whose dashboard this productionises.
Open questions raised
- Whether the first client accepts public ingress or requires the fully private (private endpoints / internal ACA ingress) deployment variant.
- When workbook authoring migrates to in-app proposals (v1.1 candidate), retiring the dual-master risk.
- Evidence-pack format alignment with the client’s regulator interactions (design-sprint item).
- Stale vault copy at
Documents/AI and Data— archive or delete to avoid future agent confusion.