Paul Miles — Taxonomy Knowledge Tool High Level Design

Tag: S-2026-05-31-paul-taxonomy-tool-hld Type: own-writing Author(s): Prepared for Paul Miles (Redstrata) Date of source: 2026-05-31 Date ingested: 2026-05-31 Authority weight: own-writing. Raw file: /Users/paulmiles/Library/CloudStorage/OneDrive-Personal/Documents/_ClaudeWorkspace/09 Taxonomy Tool/Taxonomy_Knowledge_Tool_HLD.md (and .docx).

What it claims

A High Level Design (deep technical spec, DRAFT v0.1) for a reusable, client-deployable Taxonomy Knowledge Tool that lets a regulated European retail bank build, govern, version and operate its data taxonomy and query it through AI agents, with Credit Lifecycle Monitoring as the reference use case.

Architecture (six layers). (1) Master metadata database — PostgreSQL + pgvector, the single source of truth, anchored on the Open Brain pattern; (2) MCP access layer — governed tools so AI agents read and propose changes; (3) Obsidian wiki projection — Markdown mirror generated and synced from the DB; (4) Excel extract/load bridge — governed offline analysis round-trip; (5) AI agent + skills.md layer — modular skills carrying the prior platform’s GR-01–GR-11 guardrails; (6) governance, versioning and audit engine — baselines, four-eyes approval, append-only change record.

Granularity decision (settled by primary source). The ECB Guide on effective risk data aggregation and risk reporting (May 2024) §3.4 requires “complete and up-to-date data lineages on data attribute level (starting from data capture and including extraction, transformation and loading)”, uniform definitions with ownership, and validation rules; §3.2 requires a documented “scope of application”. Conclusion: model metadata at attribute (column) level with attribute-level ETL lineage and per-attribute DQ — but only for CDEs within the documented scope of application. This bounding is the cost control; a coarser definitions-linked-to-tables model is insufficient for the in-scope set.

Reconciliation with Paul’s prior platform documents (March 2026). Those documents specify the same capabilities (18 feature categories F01–F18), the same 15 governed artefacts (A01–A15), an 11-actor user model plus 4 delivery roles, a five-phase SDLC RACI (Discover, Define, Design, Deliver & Deploy, Operate & Review), and agent guardrails GR-01–GR-11 — but a conventional REST/GraphQL/portal interface with no MCP, Obsidian or skills.md. The HLD treats the brief’s MCP/Obsidian/skills.md stack as the primary interface while preserving the prior functional requirements, artefacts and guardrails, and exposing REST/GraphQL as secondary adapters. This divergence is the one genuine decision flagged for Paul (D-7).

Build-vs-buy. Build on the Open Brain pattern for IP control, on-prem/cloud portability and no per-asset fee; keep Atlan (whose MCP-exposed active-metadata graph and column-level lineage closely mirror the design) as the explicit fallback for the lineage/DQ layers, re-tested at the Phase 3 gate. Collibra referenced for governance-workflow depth; Microsoft Purview’s per-asset pricing (~$0.50/asset/day) reinforces the scope-of-application bounding.

Delivery. Six incremental phases aligned to the CLM taxonomy glidepath: 0 Foundation; 1 Glossary + CDE (MVP); 2 Lineage + Excel; 3 DQ (build-vs-buy gate); 4 Governance/baselines/evidence; 5 Productise/multi-tenant.

Key risk. Obsidian is single-user/local-file and can clobber files open during external edit — so the wiki is positioned as a generated read/light-edit projection, with a server/Git-backed Markdown alternative to be evaluated at Phase 2.

Notable quotes

None — own-writing. (Direct regulatory quotations are attributed to the ECB May 2024 Guide inside the HLD.)

What’s speculative vs. asserted

• Asserted: the regulatory granularity requirement (attribute-level lineage incl. ETL; documented scope of application) is quoted from the ECB May 2024 Guide; the prior-document content (actors, F01–F18, A01–A15, SDLC RACI, GR-01–GR-11) is read directly from Paul’s files.
• Speculative / proposed: the architecture, DDL, phasing and build-vs-buy stance are design proposals, not yet validated by a detailed design or build; the CDE/KRI model elements are an enhancement over the prior artefact set.

Topics this feeds

• CLM Data Taxonomy Governance
• BCBS 239 and Data Lineage
• Data Governance

Open questions raised

• Interface precedence: does MCP/Obsidian/skills.md supersede the prior REST/GraphQL/portal vision, or does a client/Collibra commitment keep the prior interface primary? (D-7)
• Whether lineage traversal in Postgres + pgvector meets SLA at CLM volumes or needs a graph engine.
• Exact CRR/CRD IRB article references to pin at detailed design.

Ingestion note

Own-writing produced 2026-05-31. Sources behind the design: the brief; ECB May 2024 RDARR Guide (primary, quoted); BCBS 239; AnaCredit Reg. (EU) 2016/867; vendor references (Atlan, Collibra, Microsoft Purview); Paul’s prior 01 Taxonomy documents (agent prompts, feature capabilities, artefacts/SDLC RACI); Open Brain captures on the CLM programme and the AI & Data wiki pattern.