Paul Miles — Taxonomy Knowledge Tool HLD Addendum (Executive Q&A)
Tag: S-2026-06-01-paul-taxonomy-tool-qa-addendum
Type: own-writing
Author(s): Prepared for Paul Miles (Redstrata)
Date of source: 2026-06-01
Date ingested: 2026-06-01
Authority weight: own-writing.
Raw file: /Users/paulmiles/Library/CloudStorage/OneDrive-Personal/Documents/_ClaudeWorkspace/09 Taxonomy Tool/Taxonomy_Tool_HLD_Addendum_QA.md (and .docx).
What it claims
Executive-level answers to three follow-up questions on the Taxonomy Knowledge Tool HLD.
Q1 — Obsidian vs REST/GraphQL/portal. For a multi-user regulated bank, a REST/GraphQL API + thin web portal is materially the better human and integration surface: it provides concurrency, server-side RBAC, workflow/approval, audit, SSO and machine integration that Obsidian structurally cannot (single-user, local-file, file-clobber risk). The core (Postgres master + MCP + skills.md) is unchanged — only the human surface changes. Obsidian is demoted to Paul’s prototyping environment and an optional read-only knowledge mirror. This resolves HLD decision D-7 toward the portal for client deployments and realigns with the capabilities the prior platform documents already specified (F05/F09/F15/F17).
Q2 — Ideal client solution. A thin, bespoke “governed taxonomy system of record” (Postgres + pgvector + REST/GraphQL + MCP + thin portal + AI skills + evidence engine) that federates technical metadata, physical lineage and DQ results from whatever catalogue the client already owns, rather than rebuilding an enterprise catalogue. Lowest cost, estate-agnostic, regulator-defensible, and it keeps the differentiated IP (credit taxonomy, attribute-level lineage for in-scope CDEs, evidence packs). Deploy containerised on cloud-managed Postgres by default, on-prem via the same containers where mandated; SSO, RBAC, audit, IaC. Conditional lead choice: build the thin core for IP-independent/cost-sensitive clients; start on Purview for Microsoft/Azure-committed clients; use Atlan/Collibra for large multicloud estates — with Paul’s differentiated layer the same in every case.
Q3 — Purview-from-the-start (Microsoft/Azure client) and Purview vs Atlan. Reasonable and cost-efficient if the in-scope credit data largely lives in Azure: already owned/integrated, native enforcement on Synapse/ADLS/Power BI, unified with Microsoft security/compliance, modern governance domains + data products + active glossary + built-in DQ. Decisive caveat: Purview automates column-level lineage mainly for Microsoft/Azure sources; for on-prem/legacy golden-source credit systems lineage is manual or needs custom Apache Atlas connectors, and column-level lineage is limited (resource sets unsupported; table/view only; no query/stored-proc lineage) — exactly where RDARR’s attribute-level requirement bites. So budget for manual/custom lineage on legacy systems and enforce scope-of-application bounding to control consumption cost (~$0.50/governed asset/day). Purview differs from Atlan on estate reach (Microsoft-native vs estate-agnostic), lineage breadth (deep-in-MS vs column-level cross-source), UX (technical vs consumer-grade + MCP agent graph), and pricing (consumption vs subscription). Recommendation: don’t compete with Purview — sit Paul’s governed-taxonomy/evidence layer above it and harvest its metadata.
Notable quotes
None — own-writing. Regulatory requirements attributed to the ECB May 2024 RDARR Guide; vendor capabilities attributed to Microsoft Learn and vendor/analyst comparisons current as at June 2026.
What’s speculative vs. asserted
- Asserted: Purview’s current capabilities and lineage limitations (Microsoft Learn); the RDARR attribute-level lineage requirement (ECB May 2024); consumption pricing.
- Speculative / proposed: the “thin layer above the client’s catalogue” recommendation and the conditional lead-choice matrix are design judgements, not yet validated by a client engagement; vendor features evolve and should be reconfirmed at detailed design.
Topics this feeds
Open questions raised
- 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).
- The manual-lineage effort estimate for legacy golden-source systems under Purview.
Ingestion note
Own-writing produced 2026-06-01 as an addendum to S-2026-05-31-paul-taxonomy-tool-hld. Vendor claims verified against Microsoft Learn (Purview Unified Catalog and lineage guides) and Atlan/Promethium/PeerSpot comparisons current as at June 2026.