@evolith/core-domain 1.0.1 → 1.0.2

package/rulesets/topologies/data-mesh/data-mesh.test.rego

@@ -1,107 +0,0 @@
-package evolith.topologies.datamesh_test
-
-import data.evolith.topologies.datamesh
-
-# --- Baseline rules (DAM-R01–R03) ---
-
-test_compliant_data_mesh_has_no_violations {
-  violations := datamesh.violations with input as {"satellite": {"dataMesh": {
-    "isDataProduct": true, "hasDataContracts": true, "federatedGovernance": true,
-    "hasLineageTracking": true, "hasRetentionPolicy": true,
-    "hasConsumptionContracts": true, "hasDataQualitySLO": true,
-    "hasBackwardCompatibleContracts": true, "hasDiscoveryRegistration": true
-  }}}
-  count(violations) == 0
-}
-
-test_missing_data_product_is_rejected {
-  violations := datamesh.violations with input as {"satellite": {"dataMesh": {
-    "isDataProduct": false, "hasDataContracts": true, "federatedGovernance": true,
-    "hasLineageTracking": true, "hasRetentionPolicy": true,
-    "hasConsumptionContracts": true, "hasDataQualitySLO": true,
-    "hasBackwardCompatibleContracts": true, "hasDiscoveryRegistration": true
-  }}}
-  violations[_].id == "DAM-R01"
-}
-
-test_missing_data_contracts_is_rejected {
-  violations := datamesh.violations with input as {"satellite": {"dataMesh": {
-    "isDataProduct": true, "hasDataContracts": false, "federatedGovernance": true,
-    "hasLineageTracking": true, "hasRetentionPolicy": true,
-    "hasConsumptionContracts": true, "hasDataQualitySLO": true,
-    "hasBackwardCompatibleContracts": true, "hasDiscoveryRegistration": true
-  }}}
-  violations[_].id == "DAM-R02"
-}
-
-test_missing_federated_governance_is_rejected {
-  violations := datamesh.violations with input as {"satellite": {"dataMesh": {
-    "isDataProduct": true, "hasDataContracts": true, "federatedGovernance": false,
-    "hasLineageTracking": true, "hasRetentionPolicy": true,
-    "hasConsumptionContracts": true, "hasDataQualitySLO": true,
-    "hasBackwardCompatibleContracts": true, "hasDiscoveryRegistration": true
-  }}}
-  violations[_].id == "DAM-R03"
-}
-
-# --- New rules (DAM-R04–R09) ---
-
-test_missing_lineage_tracking_is_rejected {
-  violations := datamesh.violations with input as {"satellite": {"dataMesh": {
-    "isDataProduct": true, "hasDataContracts": true, "federatedGovernance": true,
-    "hasLineageTracking": false, "hasRetentionPolicy": true,
-    "hasConsumptionContracts": true, "hasDataQualitySLO": true,
-    "hasBackwardCompatibleContracts": true, "hasDiscoveryRegistration": true
-  }}}
-  violations[_].id == "DAM-R04"
-}
-
-test_missing_retention_policy_is_rejected {
-  violations := datamesh.violations with input as {"satellite": {"dataMesh": {
-    "isDataProduct": true, "hasDataContracts": true, "federatedGovernance": true,
-    "hasLineageTracking": true, "hasRetentionPolicy": false,
-    "hasConsumptionContracts": true, "hasDataQualitySLO": true,
-    "hasBackwardCompatibleContracts": true, "hasDiscoveryRegistration": true
-  }}}
-  violations[_].id == "DAM-R05"
-}
-
-test_missing_consumption_contracts_is_rejected {
-  violations := datamesh.violations with input as {"satellite": {"dataMesh": {
-    "isDataProduct": true, "hasDataContracts": true, "federatedGovernance": true,
-    "hasLineageTracking": true, "hasRetentionPolicy": true,
-    "hasConsumptionContracts": false, "hasDataQualitySLO": true,
-    "hasBackwardCompatibleContracts": true, "hasDiscoveryRegistration": true
-  }}}
-  violations[_].id == "DAM-R06"
-}
-
-test_missing_data_quality_slo_is_flagged {
-  violations := datamesh.violations with input as {"satellite": {"dataMesh": {
-    "isDataProduct": true, "hasDataContracts": true, "federatedGovernance": true,
-    "hasLineageTracking": true, "hasRetentionPolicy": true,
-    "hasConsumptionContracts": true, "hasDataQualitySLO": false,
-    "hasBackwardCompatibleContracts": true, "hasDiscoveryRegistration": true
-  }}}
-  violations[_].id == "DAM-R07"
-}
-
-test_missing_backward_compatible_contracts_is_flagged {
-  violations := datamesh.violations with input as {"satellite": {"dataMesh": {
-    "isDataProduct": true, "hasDataContracts": true, "federatedGovernance": true,
-    "hasLineageTracking": true, "hasRetentionPolicy": true,
-    "hasConsumptionContracts": true, "hasDataQualitySLO": true,
-    "hasBackwardCompatibleContracts": false, "hasDiscoveryRegistration": true
-  }}}
-  violations[_].id == "DAM-R08"
-}
-
-test_missing_discovery_registration_is_flagged {
-  violations := datamesh.violations with input as {"satellite": {"dataMesh": {
-    "isDataProduct": true, "hasDataContracts": true, "federatedGovernance": true,
-    "hasLineageTracking": true, "hasRetentionPolicy": true,
-    "hasConsumptionContracts": true, "hasDataQualitySLO": true,
-    "hasBackwardCompatibleContracts": true, "hasDiscoveryRegistration": false
-  }}}
-  violations[_].id == "DAM-R09"
-}

package/rulesets/topologies/data-mesh/evidence.es.md

@@ -1,111 +0,0 @@
-# Guía de Evidencia de Malla de Datos
-
-> **Navegación Bilingüe:** [English](./evidence.md) | [Español](./evidence.es.md)
-
-**Propietario:** Arquitectura de Datos
-**Topología:** Malla de Datos
-**Reglas Relacionadas:** DAM-R04, DAM-R07
-**ADRs Relacionados:** ADR-0084
-
-## Propósito
-
-Esta guía define los procedimientos de recolección y validación de evidencia para la topología de malla de datos. La evidencia valida que los productos de datos cumplen con sus SLAs de calidad declarados, los contratos son conformes, el linaje está completo y el catálogo de descubrimiento es preciso.
-
-## Comandos de Validación
-
-### Validación de Documentación
-
-```bash
-# Validación completa de documentación
-node .harness/scripts/ci/01-validate-docs.mjs
-
-# Validar contenido específico de data-mesh
-node .harness/scripts/ci/01-validate-docs.mjs --target data-mesh
-
-# Renderizar diagramas Mermaid para validación visual
-node .harness/scripts/ci/01-validate-docs.mjs --render-mermaid
-```
-
-### Validación Bilingüe
-
-```bash
-# Verificar paridad estructural EN/ES
-node .harness/scripts/ci/04-check-bilingual-parity.mjs
-
-# Verificar cobertura bilingüe
-node .harness/scripts/bilingual-coverage.mjs
-
-# Generar esqueleto ES desde archivo EN
-node .harness/scripts/generate-es-skeleton.mjs <file.md> --dry-run
-```
-
-### Cobertura y Calidad
-
-```bash
-# Generar reporte visual de cobertura
-node .harness/scripts/coverage-dashboard.mjs
-
-# Ejecutar auditoría profunda de Wilson
-node .harness/scripts/run-wilson-audit.mjs
-
-# Sanear problemas de codificación
-python ./.bmad-core/scripts/cleanup_markdown_encoding.py
-```
-
-## Métricas de Calidad
-
-### Completitud
-
-Mide la proporción de valores no nulos respecto al total de registros esperados. Los productos deben declarar umbrales de completitud como parte de sus SLAs de calidad. La completitud por debajo del umbral activa notificaciones a consumidores.
-
-Métricas objetivo: productos críticos >99.9%, productos estándar >99%, productos mejor esfuerzo >95%.
-
-### Frescura
-
-Mide el tiempo transcurrido entre la actualización de datos fuente y la disponibilidad del producto. La frescura se rastrea contra SLAs declarados. Los productos que incumplen SLAs de frescura se marcan en el catálogo de la plataforma.
-
-Granularidad de monitoreo: por producto, por dominio, por cadena de dependencias interdominio.
-
-### Validez
-
-Valida que los valores de datos se conformen a esquemas declarados y reglas de negocio. Las verificaciones de validez se ejecutan en tiempo de ingesta y bajo demanda. Los registros inválidos se cuarentenan y reportan.
-
-Métricas de validez: tasa de cumplimiento de esquema, tasa de aprobación de reglas de negocio, tasa de detección de valores atípicos.
-
-### Unicidad
-
-Asegura que no existan registros duplicados dentro de los conjuntos de datos del producto. Las restricciones de unicidad se declaran en los esquemas del producto. La detección de duplicados se ejecuta durante la ingesta y como validación por lotes.
-
-Métricas de unicidad: tasa de detección de duplicados, unicidad de clave primaria, unicidad de clave compuesta.
-
-## Completitud del Catálogo
-
-El catálogo de descubrimiento debe contener metadatos precisos para todos los productos publicados. La completitud del catálogo se mide contra: declaración de propiedad, registro de esquema, declaración de SLA, asignación de clasificación e información de contacto.
-
-Objetivos de completitud del catálogo: 100% para productos publicados, >90% para productos en borrador. Las entradas incompletas se marcan en reportes de salud de la plataforma.
-
-## Evidencia de Linaje (DAM-R04)
-
-El rastreo de linaje debe cubrir fuentes aguas arriba, lógica de transformación y consumidores aguas abajo. La evidencia de linaje se recopila a través de: instrument automatizada de flujos, anotación manual e integración con la plataforma.
-
-La completitud del linaje se mide como: porcentaje de productos con fuentes aguas arriba documentadas, porcentaje con consumidores aguas abajo documentados y porcentaje con lógica de transformación anotada.
-
-## Cumplimiento de Contratos
-
-El cumplimiento de contratos valida que los productos se adhieren a sus esquemas declarados, garantías de calidad y políticas de acceso. Las verificaciones de cumplimiento se ejecutan automáticamente contra contratos publicados.
-
-Métricas de cumplimiento: tasa de adherencia al esquema, tasa de cumplimiento de SLA, conteo de violaciones de políticas de acceso. Los productos no conformes se marcan y requieren remediación dentro de la ventana definida por la gobernanza.
-
-## Lista de Verificación
-
-- [ ] Todos los productos publicados registrados en catálogo de descubrimiento
-- [ ] Versiones de esquema actuales y compatibles backward
-- [ ] SLAs de calidad declarados y monitoreados
-- [ ] Políticas de acceso publicadas y ejecutadas
-- [ ] Documentación de linaje completa para aguas arriba y abajo
-- [ ] Campos PII declarados y con control de acceso
-- [ ] Estado de encriptación verificado
-- [ ] Cumplimiento de SLA dentro de tolerancia
-
----
-[Volver al Perfil de Malla de Datos](./README.es.md)

package/rulesets/topologies/data-mesh/evidence.md

@@ -1,111 +0,0 @@
-# Data Mesh — Evidence Guide
-
-> **Bilingual Navigation:** [English](./evidence.md) | [Español](./evidence.es.md)
-
-**Owner:** Data Architecture
-**Topology:** Data Mesh
-**Related Rules:** DAM-R04, DAM-R07
-**Related ADRs:** ADR-0084
-
-## Purpose
-
-This guide defines the evidence collection and validation procedures for data mesh topology. Evidence validates that data products meet their declared quality SLOs, contracts are compliant, lineage is complete, and the discovery catalog is accurate.
-
-## Validation Commands
-
-### Documentation Validation
-
-```bash
-# Full documentation validation
-node .harness/scripts/ci/01-validate-docs.mjs
-
-# Validate data-mesh specific content
-node .harness/scripts/ci/01-validate-docs.mjs --target data-mesh
-
-# Render Mermaid diagrams for visual validation
-node .harness/scripts/ci/01-validate-docs.mjs --render-mermaid
-```
-
-### Bilingual Validation
-
-```bash
-# Check EN/ES structural parity
-node .harness/scripts/ci/04-check-bilingual-parity.mjs
-
-# Check bilingual coverage
-node .harness/scripts/bilingual-coverage.mjs
-
-# Generate ES skeleton from EN file
-node .harness/scripts/generate-es-skeleton.mjs <file.md> --dry-run
-```
-
-### Coverage and Quality
-
-```bash
-# Generate visual coverage report
-node .harness/scripts/coverage-dashboard.mjs
-
-# Run Wilson deep audit
-node .harness/scripts/run-wilson-audit.mjs
-
-# Sanitize encoding issues
-python ./.bmad-core/scripts/cleanup_markdown_encoding.py
-```
-
-## Quality Metrics
-
-### Completeness
-
-Measure the ratio of non-null values to total expected records. Products must declare completeness thresholds as part of their quality SLOs. Completeness below threshold triggers consumer notifications.
-
-Target metrics: critical products >99.9%, standard products >99%, best-effort products >95%.
-
-### Freshness
-
-Measure the elapsed time between source data update and product availability. Freshness is tracked against declared SLAs. Products failing freshness SLAs are flagged in the platform catalog.
-
-Monitoring granularity: per-product, per-domain, per-cross-domain dependency chain.
-
-### Validity
-
-Validate that data values conform to declared schemas and business rules. Validity checks run at ingestion time and on-demand. Invalid records are quarantined and reported.
-
-Validity metrics: schema compliance rate, business rule pass rate, outlier detection rate.
-
-### Uniqueness
-
-Ensure no duplicate records exist within product datasets. Uniqueness constraints are declared in product schemas. Duplicate detection runs during ingestion and as batch validation.
-
-Uniqueness metrics: duplicate detection rate, primary key uniqueness, composite key uniqueness.
-
-## Catalog Completeness
-
-The discovery catalog must contain accurate metadata for all published products. Catalog completeness is measured against: ownership declaration, schema registration, SLA declaration, classification assignment, and contact information.
-
-Catalog completeness targets: 100% for published products, >90% for draft products. Incomplete catalog entries are flagged in platform health reports.
-
-## Lineage Evidence (DAM-R04)
-
-Lineage tracking must cover upstream sources, transformation logic, and downstream consumers. Lineage evidence is collected through: automated pipeline instrumentation, manual annotation, and platform integration.
-
-Lineage completeness is measured as: percentage of products with documented upstream sources, percentage with documented downstream consumers, and percentage with transformation logic annotated.
-
-## Contract Compliance
-
-Contract compliance validates that products adhere to their declared schemas, quality guarantees, and access policies. Compliance checks run automatically against published contracts.
-
-Compliance metrics: schema adherence rate, SLA fulfillment rate, access policy violation count. Non-compliant products are flagged and require remediation within the governance-defined window.
-
-## Validation Checklist
-
-- [ ] All published products registered in discovery catalog
-- [ ] Schema versions current and backward-compatible
-- [ ] Quality SLOs declared and monitored
-- [ ] Access policies published and enforced
-- [ ] Lineage documentation complete for upstream and downstream
-- [ ] PII fields declared and access-controlled
-- [ ] Encryption status verified
-- [ ] SLA compliance within tolerance
-
----
-[Back to Data Mesh Profile](./README.md)

package/rulesets/topologies/data-mesh/evolution.es.md

@@ -1,67 +0,0 @@
-# Guía de Evolución de Malla de Datos
-
-> **Navegación Bilingüe:** [English](./evolution.md) | [Español](./evolution.es.md)
-
-**Propietario:** Arquitectura de Datos
-**Topología:** Malla de Datos
-**Reglas Relacionadas:** DAM-R08
-**ADRs Relacionados:** ADR-0084
-
-## Propósito
-
-Esta guía define la trayectoria evolutiva desde almacenes de datos monolíticos hasta la topología de malla de datos. Cubre etapas de migración, alineación de dominios, progresión de madurez de productos, evolución de esquemas y madurez de federación. La evolución es incremental — los equipos adoptan patrones de malla progresivamente en lugar de en una sola migración.
-
-## Almacén Monolítico a Malla
-
-La migración desde un almacén centralizado sigue una progresión de cuatro etapas: extracción centralizada, extracción de dominio, formalización de producto y operación completa de malla. Cada etapa tiene criterios de salida medibles.
-
-- **Etapa 1 — Extracción Centralizada:** Los dominios comienzan a publicar conjuntos de datos propios como productos. El almacén permanece como capa de consulta principal. La plataforma proporciona descubrimiento junto al catálogo existente.
-- **Etapa 2 — Extracción de Dominio:** Los dominios asumen propiedad operativa de sus productos. La plataforma aplica políticas de acceso. El almacén se convierte en uno de muchos consumidores.
-- **Etapa 3 — Formalización de Producto:** Todos los productos tienen SLAs, esquemas y contratos declarados. Las consultas interdominio se enrutan a través de la plataforma. El almacén se descompone en almacenes de propiedad de dominio.
-- **Etapa 4 — Malla Completa:** La plataforma de autoservicio es la interfaz principal. La gobernanza federada está completamente operativa. Los dominios operan independientemente dentro de los límites de gobernanza.
-
-## Alineación de Dominios
-
-Los límites de dominio para productos de datos se alinean con los límites de dominios de negocio definidos en el mapeo organizacional de dominios. Los dominios de datos no deben crear nuevos límites organizacionales — deben reflejar los existentes.
-
-Cuando los límites de dominio son ambiguos, comenzar con la alineación más gruesa y refinar a medida que los productos maduran. La división prematura de dominios crea sobrecarga de gobernanza sin beneficio para el consumidor.
-
-## Progresión de Madurez del Producto
-
-Los productos de datos evolucionan a través de niveles de madurez que corresponden a su sofisticación operativa:
-
-- **Nivel 1 — Extracción:** Conjunto de datos crudo con metadatos básicos. Sin SLA. Solo uso interno del dominio.
-- **Nivel 2 — Producto:** Publicado con esquema, SLA y políticas de acceso. Descubrible a través de la plataforma.
-- **Nivel 3 — Gestionado:** Verificaciones de salud activas. SLAs de calidad declarados. Contratos de consumidor registrados.
-- **Nivel 4 — Optimizado:** Remediación automatizada de calidad. Linaje interdominio completo. Integrado con la plataforma.
-
-La progresión de madurez es voluntaria y dirigida por el dominio. La plataforma proporciona herramientas para soportar cada nivel pero no impone cronogramas de progresión.
-
-## Evolución de Esquemas (DAM-R08)
-
-Los cambios de esquema siguen reglas de compatibilidad backward definidas en DAM-R08. Los cambios aditivos — campos opcionales nuevos, nuevos endpoints — son no rupturantes. Eliminar o renombrar campos requiere un ciclo de deprecación con notificación a consumidores.
-
-Las versiones de esquema se rastrean en el registro de productos. Los consumidores se fijan a versiones específicas de esquema o declaran tolerancia a cambios. Los cambios rupturantes requieren una nueva versión del producto y soporte de migración.
-
-## Madurez de Federación
-
-La gobernanza federada madura a través de tres fases:
-
-- **Fase 1 — Definición de Estándares:** El órgano central define estándares mínimos. Los dominios autoevalúan cumplimiento.
-- **Fase 2 — Ejecución Automatizada:** La plataforma ejecuta estándares en registro y publicación. Las excepciones requieren aprobación del consejo de gobernanza.
-- **Fase 3 — Política como Código:** Las reglas de gobernanza se expresan como políticas legibles por máquina. Escaneo automatizado de cumplimiento. Flujos de excepción de autoservicio.
-
-Cada fase se construye sobre la anterior. Saltarse fases crea vacíos de gobernanza que son difíciles de remediar retroactivamente.
-
-## Comandos de Validación
-
-```bash
-# Verificar documentación de evolución
-node .harness/scripts/ci/01-validate-docs.mjs --target data-mesh
-
-# Verificar paridad bilingüe
-node .harness/scripts/ci/04-check-bilingual-parity.mjs
-```
-
----
-[Volver al Perfil de Malla de Datos](./README.es.md)

package/rulesets/topologies/data-mesh/evolution.md

@@ -1,67 +0,0 @@
-# Data Mesh — Evolution Guide
-
-> **Bilingual Navigation:** [English](./evolution.md) | [Español](./evolution.es.md)
-
-**Owner:** Data Architecture
-**Topology:** Data Mesh
-**Related Rules:** DAM-R08
-**Related ADRs:** ADR-0084
-
-## Purpose
-
-This guide defines the evolutionary path from monolithic data warehouses to data mesh topology. It covers migration stages, domain alignment, product maturity progression, schema evolution, and federation maturity. Evolution is incremental — teams adopt mesh patterns progressively rather than in a single migration.
-
-## Monolithic Warehouse to Mesh
-
-Migration from a centralized warehouse follows a four-stage progression: centralized extraction, domain extraction, product formalization, and full mesh operation. Each stage has measurable exit criteria.
-
-- **Stage 1 — Centralized Extraction:** Domains begin publishing owned datasets as products. Warehouse remains the primary query layer. Platform provides discovery alongside existing catalog.
-- **Stage 2 — Domain Extraction:** Domains take operational ownership of their products. Platform enforces access policies. Warehouse becomes one consumer among many.
-- **Stage 3 — Product Formalization:** All products have declared SLAs, schemas, and contracts. Cross-domain queries route through platform. Warehouse decomposes into domain-owned stores.
-- **Stage 4 — Full Mesh:** Self-serve platform is the primary interface. Federated governance is fully operational. Domains operate independently within governance guardrails.
-
-## Domain Alignment
-
-Domain boundaries for data products align with business domain boundaries defined in organizational domain mapping. Data domains should not create new organizational boundaries — they should mirror existing ones.
-
-When domain boundaries are ambiguous, start with the coarsest alignment and refine as products mature. Premature domain splitting creates governance overhead without consumer benefit.
-
-## Product Maturity Progression
-
-Data products evolve through maturity levels that correspond to their operational sophistication:
-
-- **Level 1 — Extract:** Raw dataset with basic metadata. No SLA. Internal domain use only.
-- **Level 2 — Product:** Published with schema, SLA, and access policies. Discoverable through platform.
-- **Level 3 — Managed:** Health checks active. Quality SLOs declared. Consumer contracts registered.
-- **Level 4 — Optimized:** Automated quality remediation. Cross-domain lineage complete. Platform-integrated.
-
-Maturity progression is voluntary and domain-driven. The platform provides tooling to support each level but does not mandate progression timelines.
-
-## Schema Evolution (DAM-R08)
-
-Schema changes follow backward-compatibility rules defined in DAM-R08. Additive changes — new optional fields, new endpoints — are non-breaking. Removing or renaming fields requires a deprecation cycle with consumer notification.
-
-Schema versions are tracked in the product registry. Consumers pin to specific schema versions or declare tolerance for changes. Breaking changes require a new product version and migration support.
-
-## Federation Maturity
-
-Federated governance matures through three phases:
-
-- **Phase 1 — Standards Definition:** Central body defines minimum standards. Domains self-assess compliance.
-- **Phase 2 — Automated Enforcement:** Platform enforces standards at registration and publication. Exceptions require governance council approval.
-- **Phase 3 — Policy as Code:** Governance rules expressed as machine-readable policies. Automated compliance scanning. Self-service exception workflows.
-
-Each phase builds on the previous. Skipping phases creates governance gaps that are difficult to remediate retroactively.
-
-## Validation Commands
-
-```bash
-# Verify evolution documentation
-node .harness/scripts/ci/01-validate-docs.mjs --target data-mesh
-
-# Check bilingual parity
-node .harness/scripts/ci/04-check-bilingual-parity.mjs
-```
-
----
-[Back to Data Mesh Profile](./README.md)

package/rulesets/topologies/data-mesh/fixtures/invalid.topology.config.json

@@ -1,12 +0,0 @@
-{
-  "topology": "data-mesh",
-  "isDataProduct": false,
-  "hasDataContracts": false,
-  "federatedGovernance": false,
-  "hasLineageTracking": false,
-  "hasRetentionPolicy": false,
-  "hasConsumptionContracts": false,
-  "hasDataQualitySLO": false,
-  "hasBackwardCompatibleContracts": false,
-  "hasDiscoveryRegistration": false
-}

package/rulesets/topologies/data-mesh/fixtures/valid.topology.config.json

@@ -1,12 +0,0 @@
-{
-  "topology": "data-mesh",
-  "isDataProduct": true,
-  "hasDataContracts": true,
-  "federatedGovernance": true,
-  "hasLineageTracking": true,
-  "hasRetentionPolicy": true,
-  "hasConsumptionContracts": true,
-  "hasDataQualitySLO": true,
-  "hasBackwardCompatibleContracts": true,
-  "hasDiscoveryRegistration": true
-}

package/rulesets/topologies/data-mesh/maturity.es.md

@@ -1,36 +0,0 @@
-# Guia de Adopcion, Operacion y Evolucion de Data Mesh
-
-> **Navegacion Bilingue:** [English Version](./maturity.md)
-
-## Adoption
-
-Adopte esta topologia cuando el ownership de datos analiticos debe acercarse a los equipos de dominio sin perder gobernanza, calidad, interoperabilidad ni cumplimiento. Comience con productos de datos orientados a dominio, contratos explicitos y politicas de gobernanza federada.
-
-## Operations
-
-Opere una plataforma de infraestructura de datos self-serve que soporte productos de datos propiedad de dominio. Monitoree la frescura de contratos de datos, evidencia de calidad, trazabilidad de lineage y cumplimiento normativo como parte de la validacion normal de arquitectura.
-
-## Security
-
-Autorice el acceso a datos en la frontera del producto de datos. Implemente control de acceso basado en atributos para el consumo de datos analiticos. Nunca omita el plano de gobernanza federada para consultas criticas de cumplimiento.
-
-## Resilience
-
-Disene productos de datos para actualizaciones idempotentes, tolerancia a evolucion de schema y degradacion gradual cuando los dominios upstream no esten disponibles. Prefiera consistencia eventual para la distribucion analitica.
-
-## Patterns and Anti-Patterns
-
-Use productos de datos orientados a dominio con propiedades DATSIS (Discoverable, Addressable, Trustworthy, Self-describing, Interoperable, Secure), gobernanza computacional federada y patrones de plataforma self-serve. No construya un data lake centralizado, comparta tablas operativas sin procesar entre dominios ni omita ownership de dominio por conveniencia analitica.
-
-## Evolution
-
-Migre a data mesh solo cuando la autonomia de dominio para datos analiticos este justificada por la escala organizacional. Preserve las fronteras de ownership transaccional y las politicas de gobernanza federada para que la migracion de productos de datos siga siendo deliberada.
-
-## Validation Checklist
-
-- Valide la configuracion de topologia con `topology.config.schema.json` y ambos fixtures.
-- Ejecute la evaluacion Native y OPA mediante el plano de control compartido.
-- Confirme ADRs aprobados, guia bilingue y pruebas positivas y negativas reproducibles.
-
----
-[Volver al Perfil Data Mesh](./README.es.md)

package/rulesets/topologies/data-mesh/maturity.md

@@ -1,36 +0,0 @@
-# Data Mesh Adoption, Operations, and Evolution Guide
-
-> **Bilingual Navigation:** [Version en Espanol](./maturity.es.md)
-
-## Adoption
-
-Adopt this topology when analytical data ownership must move closer to domain teams without losing governance, quality, interoperability, or compliance. Start with domain-oriented data products, explicit contracts, and federated governance policies.
-
-## Operations
-
-Operate a self-serve data infrastructure platform supporting domain-owned data products. Monitor data contract freshness, quality evidence, lineage traceability, and compliance adherence as part of normal architecture validation.
-
-## Security
-
-Authorize data access at the data product boundary. Enforce attribute-based access control for analytical data consumption. Never bypass the federated governance plane for compliance-critical queries.
-
-## Resilience
-
-Design data products for idempotent updates, schema evolution tolerance, and graceful degradation when upstream domains are unavailable. Prefer eventual consistency for analytical distribution.
-
-## Patterns and Anti-Patterns
-
-Use domain-oriented data products with DATSIS properties (Discoverable, Addressable, Trustworthy, Self-describing, Interoperable, Secure), federated computational governance, and self-serve platform patterns. Do not build a centralized data lake, share raw operational tables across domains, or bypass domain ownership for analytical convenience.
-
-## Evolution
-
-Move to data mesh only when domain autonomy for analytical data is justified by organizational scale. Preserve transactional ownership boundaries and federated governance policies so that data product migration remains deliberate.
-
-## Validation Checklist
-
-- Validate the topology configuration against `topology.config.schema.json` and both fixtures.
-- Run Native and OPA policy evaluation through the shared control plane.
-- Confirm approved ADRs, bilingual guidance, and reproducible positive and negative tests.
-
----
-[Back to Data Mesh Profile](./README.md)

package/rulesets/topologies/data-mesh/mcp/mcp-manifest.json

@@ -1,68 +0,0 @@
-{
-  "protocolVersion": "2025-03-26",
-  "topologyId": "data-mesh",
-  "description": "MCP interface for the Data Mesh topology. Provides tools for inspecting and validating data product configurations, resources for manifest and ruleset access, and prompts for mesh-governed implementation guidance.",
-  "capabilities": {
-    "tools": {},
-    "resources": {},
-    "prompts": {}
-  },
-  "tools": [
-    {
-      "name": "evolith-topology-inspect",
-      "description": "Inspect a Data Mesh topology configuration and return its parsed manifest, data domain references, and corpus artifact links.",
-      "inputSchema": {
-        "type": "object",
-        "properties": {
-          "configPath": {
-            "type": "string",
-            "description": "Path to the Data Mesh configuration file"
-          },
-          "includeDomains": {
-            "type": "boolean",
-            "description": "Include data domain references and ownership metadata"
-          }
-        },
-        "required": ["configPath"]
-      }
-    },
-    {
-      "name": "evolith-topology-validate",
-      "description": "Validate a Data Mesh configuration against the topology ruleset and OPA policies, returning pass/fail per gate.",
-      "inputSchema": {
-        "type": "object",
-        "properties": {
-          "configPath": {
-            "type": "string",
-            "description": "Path to the Data Mesh configuration to validate"
-          },
-          "strictMode": {
-            "type": "boolean",
-            "description": "Fail on warnings, not just errors"
-          }
-        },
-        "required": ["configPath"]
-      }
-    }
-  ],
-  "resources": [
-    {
-      "uri": "evolith://topologies/data-mesh/manifest",
-      "name": "Data Mesh Topology Manifest",
-      "description": "Full topology manifest for Data Mesh, including metadata, artifact references, and corpus configuration.",
-      "mimeType": "application/json"
-    },
-    {
-      "uri": "evolith://topologies/data-mesh/rulesets",
-      "name": "Data Mesh Rulesets",
-      "description": "All ruleset files for Data Mesh: native rules JSON, OPA Rego policies, and WASM bundle.",
-      "mimeType": "application/json"
-    }
-  ],
-  "prompts": [
-    {
-      "name": "topology-aware-implementation",
-      "description": "Guides AI-assisted implementation to respect Data Mesh topology constraints, data domain isolation, and federated governance."
-    }
-  ]
-}