Redstrata Knowledge Base

Taxonomy Knowledge Tool

11 min read

Taxonomy Knowledge Tool

Updated 2026-07-31 based on S-2026-07-31-weekly-briefing — adds the 2026-07-26 build-feasibility assessment: Paul can self-deliver the v1 build via Claude Code + the Ringer swarm, and environment provisioning (not code) is now the critical path. New blocker routed on the ISV Success / Azure / M365-tenant prerequisites.

Status: draft (HLD v0.2; production UI architecture v1.0 drafted; self-build feasibility assessed) Started: 2026-05-31 Last touched: 2026-07-31

Why this project exists

To design and build a reusable, client-deployable Taxonomy Knowledge Tool that lets regulated European retail banks build, govern, version and operate their data taxonomy — business glossaries, business and technical metadata, attribute-level lineage, DQ rules/results, KRIs and CDEs — and query it through AI agents, with Credit Lifecycle Monitoring as the reference use case [S-2026-05-31-paul-taxonomy-tool-hld].

Current state

  • A production solution architecture v1.0 for the UI/portal has been drafted (CLM_Taxonomy_UI_Production_Solution_Architecture.md/.docx + SVG diagram in _ClaudeWorkspace/09 Taxonomy Tool/), converting the sold dashboard wireframe into the HLD’s D-7 thin portal for a first client with an Azure/Power BI/Dynamics/React/Teams estate [S-2026-07-26-paul-taxonomy-ui-production-architecture].
  • Architecture: one React 18 / Fluent UI v9 codebase in three shells (Teams tab primary with silent Entra SSO, browser SPA, Dynamics PCF wrapper); one Node/TS REST API on Azure Container Apps (only path to the DB; MCP adapter addable later); Azure Database for PostgreSQL Flexible Server with the HLD relational core (immutable versions, proposals, approvals, append-only audit) plus a curated read-only bi schema for client Power BI; the existing Python validation pipeline productionised as a Container Apps Job reading the governed workbook from SharePoint via Graph and diffing to proposals [S-2026-07-26-paul-taxonomy-ui-production-architecture].
  • Authorisation contract: Entra app roles (Reader/Steward/Owner/Risk/Admin) assigned via the client’s existing AD security groups — JML, conditional access and access reviews stay in the client’s IAM estate; enforcement server-side [S-2026-07-26-paul-taxonomy-ui-production-architecture].
  • Resale: deployable application (versioned bundle of containers + Bicep + Entra script + Teams manifest); channel order direct → AppSource Teams listing → Azure Marketplace transactable (MACC) → partner resale; build estimate 10–14 weeks [S-2026-07-26-paul-taxonomy-ui-production-architecture].
  • Self-build feasibility assessed (2026-07-26): the 10–14-week / one-senior-engineer estimate can instead be delivered by Paul using Claude Code + the Ringer swarm for the engineering — but not compressed on the calendar, because Entra app registrations, Graph Sites.Selected admin consent, security review, Teams publishing and steward UAT sit on the client’s clock. Estimated ~4–5 weeks of Paul’s effort to a demoable v1 in a tenant he controls, then client staging→prod gated by client access — end-to-end still inside the original 10–14 weeks but without paying a senior engineer for three months and with Paul owning the resellable artefact. Recommended shape is contract-first, then swarm: a Phase 0 (2–3 days, Claude Code with Paul, not swarm) freezes OpenAPI 3.1, Postgres DDL + migration plan, shared TS types, RBAC matrix, audit event schema, fixtures and the machine verify-gates every swarm task must pass; only independent, checkable leaves are routed to Ringer (endpoint+contract test, migration+rollback test, one Bicep module, one component+snapshot) — the four-eyes/audit spine is built by hand with invariants as failing tests first [S-2026-07-31-weekly-briefing].
  • Environment provisioning is now the critical path, not code: Paul currently holds none of the prerequisites (no own Azure subscription, no M365 developer tenant, no client Azure/Entra access, no git repo with CI). The M365 E5 developer sandbox is no longer open to individuals; recommended route is to join ISV Success (free, and the same enrolment underpinning the AppSource→Azure Marketplace resale channel already chosen), with fallbacks of a paid VS Pro standard subscription or a paid M365 Business Basic tenant on a domain Paul owns; an Azure PAYG subscription has no eligibility gate. Design mandate: tenant-agnostic from line one (no hardcoded tenant/site IDs; config via Key Vault + Bicep parameter files) so the client deployment is a parameter file, not a port. D365 PCF deferred to v1.1 [S-2026-07-31-weekly-briefing].
  • The underlying HLD remains DRAFT v0.2 (see History for the earlier state summary).

Earlier state (2026-06-01 → 2026-07-04, retained)

A High Level Design (deep technical spec, now DRAFT v0.2) has been produced and saved to _ClaudeWorkspace/09 Taxonomy Tool/ as .md and .docx with eight diagrams (incl. the Figure 8 reference deployment), plus an executive Q&A addendum [S-2026-05-31-paul-taxonomy-tool-hld][S-2026-06-01-paul-taxonomy-tool-qa-addendum]. Key design positions:

  • Six-layer architecture: PostgreSQL + pgvector master DB; MCP access layer; Obsidian wiki projection; Excel extract/load bridge; AI agent + skills.md layer; governance/versioning/audit engine [S-2026-05-31-paul-taxonomy-tool-hld].
  • Granularity is settled by primary source, not assumed: the ECB May 2024 RDARR Guide requires attribute-level lineage including ETL and a documented scope of application, so metadata is modelled at attribute (column) level with attribute-level lineage and per-attribute DQ — bounded to CDEs within the scope of application [S-2026-05-31-paul-taxonomy-tool-hld].
  • Anchored on the Open Brain + AI & Data wiki pattern, with Atlan held as the explicit build-vs-buy fallback for the lineage/DQ layers [S-2026-05-31-paul-taxonomy-tool-hld].
  • Reconciles Paul’s prior platform documents (18 features F01–F18, 15 artefacts A01–A15, 11 actors + 4 delivery roles, five-phase SDLC RACI, guardrails GR-01–GR-11) as the functional baseline, while adopting the brief’s MCP/Obsidian/skills.md interface [S-2026-05-31-paul-taxonomy-tool-hld].

Decisions made

  • 2026-05-31 — Adopt attribute-level granularity bounded to the documented scope of application, on the authority of the ECB May 2024 RDARR Guide §3.2 / §3.4 [S-2026-05-31-paul-taxonomy-tool-hld].
  • 2026-05-31 — Anchor on the Open Brain pattern (Postgres + pgvector + MCP) and the AI & Data Obsidian wiki pattern; keep Atlan as the Phase 3 build-vs-buy fallback [S-2026-05-31-paul-taxonomy-tool-hld].
  • 2026-05-31 — Position the Obsidian wiki as a generated read/light-edit projection (not the multi-user authoring surface) to mitigate its single-user/file-clobber risk [S-2026-05-31-paul-taxonomy-tool-hld].
  • 2026-06-01 — D-7 resolved (for client deployments): make REST/GraphQL + MCP + a thin web portal the primary multi-user surface; demote Obsidian to Paul’s prototyping environment and an optional read-only knowledge mirror. Rationale: only the API/portal provides concurrency, server-side RBAC, workflow and audit a regulated bank requires — and it realigns with the prior platform documents’ F05/F09/F15/F17 [S-2026-06-01-paul-taxonomy-tool-qa-addendum].
  • 2026-06-01 — Ideal deployment pattern: a thin bespoke governed-taxonomy/evidence layer that federates from the client’s existing catalogue (harvests technical metadata, physical lineage, DQ results) rather than rebuilding an enterprise catalogue — lowest cost, estate-agnostic, keeps the differentiated IP [S-2026-06-01-paul-taxonomy-tool-qa-addendum].
  • 2026-07-26 — First-client hosting: deploy into the client’s Azure tenant via Bicep IaC (not Redstrata-hosted SaaS, not hybrid) — aligns with the client’s Azure ODS, Entra SSO, data residency and bank procurement norms (Paul, in-session) [S-2026-07-26-paul-taxonomy-ui-production-architecture].
  • 2026-07-26 — v1 scope: read surface plus governed approval workflow (proposal → review → approve, four-eyes, append-only audit), replacing the wireframe’s demo overlay with real state; lineage/DQ/pgvector/MCP deferred to later phases per the HLD roadmap (Paul, in-session) [S-2026-07-26-paul-taxonomy-ui-production-architecture].
  • 2026-07-26 — Resale packaging: a deployable application (versioned containers + Bicep + Entra script + Teams manifest; per-client parameters, no forks) rather than a React component library; channel order direct → AppSource → Azure Marketplace transactable (MACC) → partner resale (Paul, in-session) [S-2026-07-26-paul-taxonomy-ui-production-architecture].
  • 2026-07-26 — Build the v1 himself (Claude Code + Ringer swarm), contract-first: freeze the API/DDL/types/RBAC/audit-schema/verify-gates in a Phase 0, then route only independent checkable leaves to the swarm and hand-build the four-eyes/audit spine; provision environments via ISV Success + Azure PAYG rather than hiring a senior engineer for three months [S-2026-07-31-weekly-briefing].
  • 2026-06-01 — Purview-from-start guidance: acceptable for Microsoft/Azure-committed clients whose in-scope data sits in Azure, provided scope-of-application bounding controls consumption cost and budget is set aside for manual/custom attribute-level lineage on on-prem/legacy golden-source systems (the RDARR pressure point). Otherwise sit Paul’s layer above Purview and harvest its metadata [S-2026-06-01-paul-taxonomy-tool-qa-addendum].

Open questions / blockers

  • Whether the first client’s in-scope CLM credit data sits mostly in Azure (favours Purview) or on-prem/legacy (favours the thin federation layer) [S-2026-06-01-paul-taxonomy-tool-qa-addendum].
  • Whether lineage traversal in Postgres + pgvector meets SLA at CLM volumes or needs a graph engine (Apache AGE / Neo4j) [S-2026-05-31-paul-taxonomy-tool-hld].
  • Exact CRR/CRD IRB article references to pin at detailed design [S-2026-05-31-paul-taxonomy-tool-hld].
  • Cloud vs on-premise lead deployment for the first client [S-2026-05-31-paul-taxonomy-tool-hld]. Resolved 2026-07-26: client’s Azure tenant, Bicep-deployed [S-2026-07-26-paul-taxonomy-ui-production-architecture].
  • Whether the first client accepts public ingress or requires the fully private deployment variant (private endpoints, internal ACA ingress) [S-2026-07-26-paul-taxonomy-ui-production-architecture].
  • When workbook authoring migrates to in-app proposals (v1.1 candidate), retiring the dual-master drift risk [S-2026-07-26-paul-taxonomy-ui-production-architecture].
  • Evidence-pack format alignment with the client’s regulator interactions (design-sprint item) [S-2026-07-26-paul-taxonomy-ui-production-architecture].
  • 2026-07-31 (weekly briefing) — environment provisioning must start before build can begin. The Week 0 pack (ISV Success enrolment, contract-freeze spec, Ringer task shapes with verify gates, client access-request note) was offered but is not confirmed started; until Paul holds a controllable Azure/M365 tenant and (later) client Entra access, the ~4–5-week self-build cannot begin. This is now the binding constraint on the project [S-2026-07-31-weekly-briefing].
  • 2026-06-05 (weekly briefing) — three decisions await Paul’s sign-off to move the HLD from draft to a deployable offer: (1) confirm the D-7 resolution toward the REST/GraphQL + MCP + thin-portal surface; (2) confirm “federation / thin layer above the client’s existing catalogue” as the default deployment model; (3) flag any client with a hard Collibra or prior-UI commitment (where the portal becomes that product’s UI with this tool federating beneath) [S-2026-06-05-weekly-briefing].

Connected wiki pages

History

  • 2026-07-26 — Self-build feasibility assessed (with Paul): the v1 can be delivered by Paul via Claude Code + the Ringer swarm on a contract-first, then-swarm shape (~4–5 weeks of Paul’s effort to a demoable v1, end-to-end still inside the original 10–14 weeks), with environment provisioning — not code — established as the critical path and the M365 E5 developer-sandbox eligibility change forcing the ISV Success / Azure PAYG provisioning route. Routed into the wiki via the weekly briefing [S-2026-07-31-weekly-briefing].
  • 2026-07-26 — Production solution architecture v1.0 drafted for the UI/portal (client-Azure-tenant deployment, React/Fluent three-shell UI, Node/TS API on Container Apps, Postgres Flexible Server, governed SharePoint/Graph ingestion, Entra app-role RBAC, deployable-application packaging with AppSource/Marketplace channel plan). Current state rewritten; the prior state summary (HLD v0.2 + wireframe) is retained under “Earlier state” within Current state and in the entries below [S-2026-07-26-paul-taxonomy-ui-production-architecture].
  • 2026-07-04 — Interactive dashboard wireframe delivered demonstrating the thin-portal surface for CLM taxonomy governance: single-file HTML (Teams-native light styling), seeded with the 201-term CLM Industry Business Glossary; views for dashboard KPIs/heatmap, glossary browsing, governance workflow, regulator evidence (CSV pack export) and Metadata/Lineage/DQ roadmap tabs; persona toggle for Business Data Owner / Business User / Credit Risk; publishable via SharePoint as a Teams tab with the Excel flat file as governed source. Deliverables + data-flow diagram + Proposed-vs-Actual record in _ClaudeWorkspace/11 CLM Taxonomy Dashboard/ [S-2026-07-04-paul-clm-taxonomy-dashboard].
  • 2026-05-31 — HLD v0.1 produced from the brief, the ECB May 2024 RDARR Guide (primary), BCBS 239, AnaCredit, vendor references (Atlan/Collibra/Purview), Paul’s prior 01 Taxonomy platform documents, and Open Brain captures. Seven diagrams generated; .md + .docx delivered.
  • 2026-06-01 — Executive Q&A addendum produced (Obsidian vs portal; ideal deployment; Purview-from-start vs Atlan), with fresh vendor research; .md + .docx delivered. D-7 resolved toward the portal for client deployments.
  • 2026-06-01 — HLD revised to v0.2: folded the Q&A decisions into the main document — D-7 resolved (REST/GraphQL + MCP + thin portal primary; Obsidian demoted to prototyping/optional read-only mirror); added §4.7 (API + portal), §4.8 (federation/harvest layer), and §17 Reference deployment — thin governed layer above an existing catalogue (Purview worked example) with a new Figure 8; risk R-1 downgraded, R-1b (Purview legacy-lineage gap) added [S-2026-06-01-paul-taxonomy-tool-qa-addendum].

Sources / notes

  • [S-2026-05-31-paul-taxonomy-tool-hld] — Taxonomy Knowledge Tool High Level Design (own-writing).
  • [S-2026-06-01-paul-taxonomy-tool-qa-addendum] — HLD Addendum, Executive Q&A (own-writing).
  • [S-2026-07-26-paul-taxonomy-ui-production-architecture] — Taxonomy UI production solution architecture, session record (own-writing).
  • [S-2026-07-31-weekly-briefing] — Weekly Briefing 31 Jul 2026 (own-writing): routed the self-build feasibility assessment and the environment-provisioning-as-critical-path finding into this page.

Graph View

Backlinks

Recently updated

See 113 more →