@evolith/core-domain 1.0.0 → 1.0.1

package/rulesets/topologies/agentic-ai/topology.manifest.json

@@ -0,0 +1,127 @@
+{
+  "apiVersion": "evolith.dev/topology/v1",
+  "kind": "TopologyManifest",
+  "metadata": {
+    "id": "agentic-ai",
+    "name": "Agentic AI",
+    "dimension": "ai",
+    "status": "accepted",
+    "version": "0.1.0",
+    "governance": {
+      "owner": "AI Architecture",
+      "criticality": "P1"
+    }
+  },
+  "spec": {
+    "summary": "AI-first and agentic workflow topology for MCP-enabled context injection, governed tools, auditable actions, and architecture-aware implementation assistance.",
+    "topologyType": "agentic-ai",
+    "compatibility": {
+      "progressiveAxis": {
+        "phase": "cross",
+        "profile": "cross"
+      },
+      "composableWith": [
+        "modular-monolith",
+        "distributed-modules",
+        "microservices",
+        "serverless",
+        "event-driven",
+        "data-mesh",
+        "edge-computing"
+      ]
+    },
+    "artifacts": {
+      "adrs": [
+        "reference/architecture/adrs/core/0058-ai-consumable-architecture-knowledge.md",
+        "reference/architecture/adrs/core/0081-agentic-ai-sandbox-isolation.md",
+        "reference/architecture/adrs/core/0082-agentic-ai-trust-boundary.md",
+        "reference/architecture/adrs/core/0083-agentic-ai-action-authorization-audit.md",
+        "reference/architecture/adrs/core/0079-multi-topology-reference-corpus.md"
+      ],
+      "rulesets": [
+        "rulesets/topologies/agentic-ai/agentic-ai.rules.json"
+      ],
+      "opaPolicies": [
+        "rulesets/topologies/agentic-ai/agentic-ai.rego"
+      ],
+      "aiRulesets": [
+        "rulesets/topologies/agentic-ai/README.md",
+        "rulesets/topologies/agentic-ai/maturity.md",
+        "rulesets/topologies/agentic-ai/adoption.md",
+        "rulesets/topologies/agentic-ai/operations.md",
+        "rulesets/topologies/agentic-ai/security.md",
+        "rulesets/topologies/agentic-ai/resilience.md",
+        "rulesets/topologies/agentic-ai/patterns.md",
+        "rulesets/topologies/agentic-ai/evolution.md"
+      ],
+      "umsContracts": [
+        "reference/knowledge/demo/ums-reference-model.md"
+      ]
+    },
+    "corpus": {
+      "guidance": {
+        "profile": "rulesets/topologies/agentic-ai/README.md",
+        "maturityGuide": "rulesets/topologies/agentic-ai/maturity.md"
+      },
+      "configurationContract": "rulesets/topologies/agentic-ai/agent.config.schema.json",
+      "fixtures": {
+        "valid": "rulesets/topologies/agentic-ai/fixtures/valid-agent.config.json",
+        "invalid": "rulesets/topologies/agentic-ai/fixtures/invalid-agent.config.json"
+      },
+      "nativeEvaluator": "packages/core-domain/src/application/validators/evaluators/handlers/architecture-rule.handler.ts",
+      "tests": {
+        "positive": "packages/core-domain/src/application/validators/evaluators/handlers/architecture-rule.handler.spec.ts",
+        "negative": "packages/core-domain/src/application/validators/evaluators/handlers/architecture-rule.handler.spec.ts"
+      },
+      "evidence": "rulesets/topologies/agentic-ai/evidence.md"
+    },
+    "operationalBudgets": {
+      "tokenBudgetPerExecution": 100000,
+      "credentialRotationIntervalHours": 24,
+      "sandboxTimeoutMs": 30000
+    },
+    "operationalInterfaces": {
+      "cli": {
+        "validators": [
+          "validate-topology"
+        ]
+      },
+      "mcp": {
+        "resources": [
+          "evolith://topologies/agentic-ai/manifest",
+          "evolith://topologies/agentic-ai/rulesets",
+          "evolith://topologies/agentic-ai/mcp"
+        ],
+        "tools": [
+          "evolith-topology-inspect",
+          "evolith-topology-validate",
+          "evolith-ruleset-explain"
+        ],
+        "prompts": [
+          "topology-aware-implementation",
+          "agentic-ai-governance-review",
+          "adr-impact-analysis"
+        ]
+      },
+      "coreApi": {
+        "endpoints": [
+          "GET /topologies/{id}",
+          "GET /topologies/{id}/manifest",
+          "POST /topologies/{id}/validate"
+        ]
+      }
+    }
+  },
+  "businessBoundary": {
+    "technicalOnly": true,
+    "trackerOwns": [
+      "timing",
+      "ownership",
+      "prioritization",
+      "roi",
+      "cost",
+      "budget",
+      "funnel-0"
+    ]
+  }
+}

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

@@ -0,0 +1,69 @@
+# Perfil Topologico Data Mesh
+
+> **Navegacion Bilingue:** [English Version](./README.md)
+
+**Estado:** Accepted  
+**Dimension:** `data`  
+**ID de Topologia:** `data-mesh`  
+**Alias de Compatibilidad:** `F2-compatible`  
+**Manifiesto:** [topology.manifest.json](./topology.manifest.json)
+
+Data mesh es una topologia de datos para ownership analitico distribuido, productos de datos gobernados, contratos descubribles e interoperabilidad soportada por plataforma entre dominios.
+
+## Proposito
+
+Usa esta topologia cuando el ownership de datos analiticos debe acercarse a los equipos de dominio sin perder gobernanza, calidad, interoperabilidad ni cumplimiento.
+
+Data mesh no debilita el ownership transaccional. Las fronteras de datos de dominio permanecen gobernadas por el bounded context o servicio propietario.
+
+## Reglas de Gobernanza
+
+| Regla | Requisito |
+|---|---|
+| Ownership de dominio | Los productos de datos deben alinearse a dominios delimitados u ownership de servicio. |
+| Productos contratados | Los productos de datos deben publicar schemas, expectativas de calidad y metadata de ciclo de vida. |
+| Interoperabilidad | Los datos compartidos deben usar contratos gobernados y semantica descubrible. |
+| Evidencia de calidad | Los productos de datos deben exponer validacion, lineage, frescura y senales de confiabilidad. |
+| Frontera transaccional | La distribucion analitica no debe saltarse ownership transaccional ni invariantes de dominio. |
+
+## Autoridad Requerida
+
+| Artefacto | Rol |
+|---|---|
+| [ADR-0084: Data Mesh y Datos como Producto](../../../adrs/core/0084-data-mesh-data-products.md) | Gobierna la topologia data mesh y los contratos de productos de datos. |
+| [ADR-0079: Corpus de Referencia Multi-Topologia](../../../adrs/core/0079-multi-topology-reference-corpus.md) | Gobierna los manifiestos de topologia y composicion. |
+| [Reglas de Arquitectura Data Mesh](./data-mesh.rules.json) | Reglas de compatibilidad ejecutables existentes. |
+| [Modelo de Dimensiones de Topologia](../../topology-dimensions.md) | Define reglas de composicion y compatibilidad. |
+
+## Contrato Ejecutable
+
+Todo satelite que adopte este perfil proporcionando o consumiendo productos de datos debe proporcionar `data-mesh.config.json`:
+
+```json
+{
+  "isDataProduct": true,
+  "hasDataContracts": true,
+  "federatedGovernance": true
+}
+```
+
+DM-R01 a DM-R03 exigen ese contrato, forzando la designacion explicita de Data Product, la presencia de Data Contracts para interoperabilidad, y el cumplimiento de las politicas de gobernanza federada. El evaluador Native y la [politica OPA](./data-mesh.rego) evaluan estos campos.
+
+## Composicion
+
+`data-mesh` puede combinarse con:
+
+| Topologia | Por Que Puede Componerse |
+|---|---|
+| `distributed-modules` | Habilita productos de datos analiticos propiedad de modulos de dominio con contratos gobernados. |
+| `microservices` | Soporta productos de datos con propiedad independiente alineados a fronteras de servicio. |
+| `event-driven` | Impulsa actualizaciones de productos de datos a traves de canales de eventos observables. |
+| `serverless` | Proporciona ejecucion de productos de datos analiticos sin acoplamiento transaccional. |
+| `agentic-ai` | Alimenta workflows de agentes IA con productos de datos analiticos gobernados. |
+
+## Frontera de Negocio
+
+Este perfil es solo tecnico. No define monetizacion de datos, ROI, asignacion de costos, staffing, priorizacion, timing de entrega ni Funnel 0. Evolith Tracker posee esas preocupaciones de negocio mediante su ACL.
+
+---
+[Volver al Hub de Topologias](../../README.es.md)

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

@@ -0,0 +1,69 @@
+# Data Mesh Topology Profile
+
+> **Bilingual Navigation:** [Version en Espanol](./README.es.md)
+
+**Status:** Accepted  
+**Dimension:** `data`  
+**Topology ID:** `data-mesh`  
+**Compatibility Alias:** `F2-compatible`  
+**Manifest:** [topology.manifest.json](./topology.manifest.json)
+
+Data mesh is a data topology for distributed analytical ownership, governed data products, discoverable contracts, and platform-supported interoperability across domains.
+
+## Purpose
+
+Use this topology when analytical data ownership must move closer to domain teams without losing governance, quality, interoperability, or compliance.
+
+Data mesh does not weaken transactional ownership. Domain data boundaries remain governed by the owning bounded context or service.
+
+## Governance Rules
+
+| Rule | Requirement |
+|---|---|
+| Domain ownership | Data products must align to bounded domains or service ownership. |
+| Contracted products | Data products must publish schemas, quality expectations, and lifecycle metadata. |
+| Interoperability | Shared data must use governed contracts and discoverable semantics. |
+| Quality evidence | Data products must expose validation, lineage, freshness, and reliability signals. |
+| Transactional boundary | Analytical distribution must not bypass transactional ownership or domain invariants. |
+
+## Required Authority
+
+| Artifact | Role |
+|---|---|
+| [ADR-0084: Data Mesh and Data as a Product](../../../adrs/core/0084-data-mesh-data-products.md) | Governs data mesh topology and data product contracts. |
+| [ADR-0079: Multi-Topology Reference Corpus](../../../adrs/core/0079-multi-topology-reference-corpus.md) | Governs topology manifests and composition. |
+| [Data Mesh Architecture Rules](./data-mesh.rules.json) | Existing executable compatibility rules. |
+| [Topology Dimensions Model](../../topology-dimensions.md) | Defines composition and compatibility rules. |
+
+## Executable Contract
+
+Every adopting satellite providing or consuming data products must provide `data-mesh.config.json`:
+
+```json
+{
+  "isDataProduct": true,
+  "hasDataContracts": true,
+  "federatedGovernance": true
+}
+```
+
+DM-R01 through DM-R03 require that contract, enforcing explicit Data Product designation, the presence of Data Contracts for interoperability, and adherence to federated governance policies. The Native evaluator and [OPA policy](./data-mesh.rego) evaluate these fields.
+
+## Composition
+
+`data-mesh` can combine with:
+
+| Topology | Why It Can Compose |
+|---|---|
+| `distributed-modules` | Enables analytical data products owned by domain modules with governed contracts. |
+| `microservices` | Supports independently owned data products aligned to service boundaries. |
+| `event-driven` | Drives data product updates through observable event channels. |
+| `serverless` | Provides analytical data product execution without transactional coupling. |
+| `agentic-ai` | Feeds AI-agent workflows with governed analytical data products. |
+
+## Business Boundary
+
+This profile is technical-only. It does not define data monetization, ROI, cost allocation, staffing, prioritization, delivery timing, or Funnel 0. Evolith Tracker owns those business concerns through its ACL.
+
+---
+[Back to Topology Hub](../../README.md)

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

@@ -0,0 +1,95 @@
+# Guía de Adopción de Malla de Datos
+
+> **Navegación Bilingüe:** [English](./adoption.md) | [Español](./adoption.es.md)
+
+**Propietario:** Arquitectura de Datos
+**Topología:** Malla de Datos
+**Reglas Relacionadas:** DAM-R01, DAM-R03, DAM-R09
+
+## Propósito
+
+Esta guía define los criterios de entrada, el proceso de incorporación de dominios, el flujo de creación de productos y la lista de verificación de preparación para adoptar la topología de malla de datos. La adopción es dirigida por el dominio — cada dominio ingresa a la malla cuando cumple los criterios de preparación y tiene capacidad operativa.
+
+## Criterios de Entrada
+
+Los dominios deben satisfacer los siguientes criterios antes de ingresar a la malla de datos:
+
+- **Límite de Dominio Establecido:** Propiedad clara de dominio de negocio con un líder de dominio designado.
+- **Líder de Producto de Datos Identificado:** Al menos una persona responsable del ciclo de vida del producto de datos.
+- **Acceso a la Plataforma Concedido:** El equipo de dominio tiene acceso autenticado a la plataforma de autoservicio.
+- **Capacitación de Gobernanza Completada:** El equipo de dominio ha completado la orientación de gobernanza federada.
+- **Producto Inicial Identificado:** Al menos un conjunto de datos listo para formalización como producto.
+
+Los dominios que no cumplan todos los criterios pueden participar solo como consumidores. La participación como consumidor requiere acceso a la plataforma y capacitación de gobernanza pero no propiedad de productos.
+
+## Incorporación de Dominios
+
+La incorporación sigue un proceso estructurado de cinco pasos:
+
+1. **Registro del Dominio:** Registrar el dominio en la plataforma con contactos de propiedad y descripción de límites.
+2. **Alineación de Gobernanza:** Revisar y reconocer los estándares corporativos de gobernanza de datos. Configurar políticas específicas del dominio.
+3. **Incorporación a la Plataforma:** Configurar el espacio de trabajo del dominio, controles de acceso e integraciones de monitoreo.
+4. **Identificación de Productos:** Identificar conjuntos de datos candidatos para formalización como producto. Priorizar por demanda de consumidores y calidad de datos.
+5. **Lanzamiento del Producto Piloto:** Crear y publicar un producto piloto siguiendo la guía de creación de productos.
+
+Duración de incorporación: habitualmente 2-4 semanas dependiendo de la complejidad del dominio y la madurez de datos existente.
+
+## Guía de Creación de Productos
+
+### Paso 1 — Definir el Producto
+
+- Nombrar el producto con un identificador claro y específico del dominio.
+- Definir la descripción del producto y los consumidores previstos.
+- Clasificar los datos según los niveles corporativos de clasificación.
+- Identificar fuentes de datos aguas arriba y consumidores aguas abajo.
+
+### Paso 2 — Diseñar el Esquema
+
+- Definir el esquema de salida con campos tipificados.
+- Declarar claves primarias y restricciones de unicidad.
+- Marcar campos PII explícitamente.
+- Documentar descripciones de campos y definiciones de negocio.
+
+### Paso 3 — Establecer SLAs de Calidad
+
+- Definir umbrales de completitud, frescura, validez y unicidad según DAM-R07.
+- Alinear SLAs con requisitos de consumidores y nivel de SLA.
+- Configurar horario de verificaciones de salud y alertas.
+
+### Paso 4 — Configurar Políticas de Acceso
+
+- Definir controles de acceso basados en roles por producto.
+- Publicar políticas de acceso en la plataforma.
+- Configurar flujo de incorporación de consumidores.
+
+### Paso 5 — Registrar y Publicar
+
+- Registrar el producto en el índice de descubrimiento según DAM-R09.
+- Validar completitud del registro.
+- Publicar el producto y notificar a consumidores iniciales.
+
+## Lista de Verificación de Preparación
+
+- [ ] Dominio registrado en la plataforma
+- [ ] Líder de dominio y líder de producto de datos designados
+- [ ] Capacitación de gobernanza completada
+- [ ] Espacio de trabajo de la plataforma configurado
+- [ ] Esquema del producto piloto definido
+- [ ] SLAs de calidad declarados
+- [ ] Políticas de acceso publicadas
+- [ ] Producto registrado en índice de descubrimiento
+- [ ] Notificación a consumidores enviada
+- [ ] Verificaciones de salud configuradas
+
+## Comandos de Validación
+
+```bash
+# Verificar documentación de adopció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/adoption.md

@@ -0,0 +1,95 @@
+# Data Mesh — Adoption Guide
+
+> **Bilingual Navigation:** [English](./adoption.md) | [Español](./adoption.es.md)
+
+**Owner:** Data Architecture
+**Topology:** Data Mesh
+**Related Rules:** DAM-R01, DAM-R03, DAM-R09
+
+## Purpose
+
+This guide defines the entry criteria, domain onboarding process, product creation workflow, and readiness checklist for adopting data mesh topology. Adoption is domain-driven — each domain enters the mesh when it meets readiness criteria and has operational capacity.
+
+## Entry Criteria
+
+Domains must satisfy the following criteria before entering the data mesh:
+
+- **Domain Boundary Established:** Clear business domain ownership with a designated domain lead.
+- **Data Product Lead Identified:** At least one person accountable for data product lifecycle.
+- **Platform Access Granted:** Domain team has authenticated access to the self-serve platform.
+- **Governance Training Complete:** Domain team has completed federated governance orientation.
+- **Initial Product Identified:** At least one dataset ready for product formalization.
+
+Domains that do not meet all criteria may participate as consumers only. Consumer participation requires platform access and governance training but not product ownership.
+
+## Domain Onboarding
+
+Onboarding follows a structured five-step process:
+
+1. **Domain Registration:** Register the domain in the platform with ownership contacts and boundary description.
+2. **Governance Alignment:** Review and acknowledge corporate data governance standards. Configure domain-specific policies.
+3. **Platform Onboarding:** Configure domain workspace, access controls, and monitoring integrations.
+4. **Product Identification:** Identify candidate datasets for product formalization. Prioritize by consumer demand and data quality.
+5. **Pilot Product Launch:** Create and publish one pilot product following the product creation guide.
+
+Onboarding duration: typically 2-4 weeks depending on domain complexity and existing data maturity.
+
+## Product Creation Guide
+
+### Step 1 — Define the Product
+
+- Name the product with a clear, domain-specific identifier.
+- Define the product description and intended consumers.
+- Classify the data per corporate classification tiers.
+- Identify upstream data sources and downstream consumers.
+
+### Step 2 — Design the Schema
+
+- Define the output schema with typed fields.
+- Declare primary keys and uniqueness constraints.
+- Mark PII fields explicitly.
+- Document field descriptions and business definitions.
+
+### Step 3 — Set Quality SLOs
+
+- Define completeness, freshness, validity, and uniqueness thresholds per DAM-R07.
+- Align SLOs with consumer requirements and SLA tier.
+- Configure health check schedule and alerting.
+
+### Step 4 — Configure Access Policies
+
+- Define role-based access controls per product.
+- Publish access policies to the platform.
+- Configure consumer onboarding workflow.
+
+### Step 5 — Register and Publish
+
+- Register the product in the discovery index per DAM-R09.
+- Validate registration completeness.
+- Publish the product and notify initial consumers.
+
+## Readiness Checklist
+
+- [ ] Domain registered in platform
+- [ ] Domain lead and data product lead designated
+- [ ] Governance training completed
+- [ ] Platform workspace configured
+- [ ] Pilot product schema defined
+- [ ] Quality SLOs declared
+- [ ] Access policies published
+- [ ] Product registered in discovery index
+- [ ] Consumer notification sent
+- [ ] Health checks configured
+
+## Validation Commands
+
+```bash
+# Verify adoption 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/cli/cli-flows.es.md

@@ -0,0 +1,41 @@
+# Data Mesh — Flujos CLI
+
+> **Navegación Bilingüe:** [English Version](./cli-flows.md)
+
+**Validadores declarados:** `validate-architecture`, `validate-topology`
+
+## Validate
+
+```bash
+evolith validate --topology data-mesh
+evolith validate --topology data-mesh --arch-level F2
+evolith validate --topology data-mesh --format json
+```
+
+## Inspect
+
+```bash
+evolith topology inspect data-mesh
+evolith topology inspect data-mesh --include-domains
+```
+
+## Drift
+
+```bash
+evolith drift detect --topology data-mesh
+evolith drift detect --topology data-mesh --format json
+```
+
+## Scaffold
+
+```bash
+evolith architecture scaffold --topology data-mesh
+evolith architecture scaffold --topology data-mesh --dry-run
+```
+
+## Gate Evaluation
+
+```bash
+evolith gate evaluate --topology data-mesh
+evolith gate evaluate --topology data-mesh --phase F1
+```

package/rulesets/topologies/data-mesh/cli/cli-flows.md

@@ -0,0 +1,53 @@
+# Data Mesh — CLI Flows
+
+> **Bilingual Navigation:** [Versión en Español](./cli-flows.es.md)
+
+**Validators declarados:** `validate-architecture`, `validate-topology`
+
+The following CLI commands are available for the Data Mesh topology.
+
+## Validate
+
+```bash
+evolith validate --topology data-mesh
+evolith validate --topology data-mesh --arch-level F2
+evolith validate --topology data-mesh --format json
+```
+
+Validates a Data Mesh configuration against the topology's native rules (`data-mesh.rules.json`) and OPA Rego policies (`data-mesh.rego`), checking data domain isolation, federated governance, and contract boundaries.
+
+## Inspect
+
+```bash
+evolith topology inspect data-mesh
+evolith topology inspect data-mesh --include-domains
+```
+
+Returns the parsed Data Mesh topology manifest, data domain references, ownership metadata, and corpus artifact links.
+
+## Drift
+
+```bash
+evolith drift detect --topology data-mesh
+evolith drift detect --topology data-mesh --format json
+```
+
+Detects configuration drift between the Data Mesh topology's declared ruleset and the current workspace state.
+
+## Scaffold
+
+```bash
+evolith architecture scaffold --topology data-mesh
+evolith architecture scaffold --topology data-mesh --dry-run
+```
+
+Scaffolds a Data Mesh topology workspace with the canonical corpus structure, manifest, config schema, and OPA policies.
+
+## Gate Evaluation
+
+```bash
+evolith gate evaluate --topology data-mesh
+evolith gate evaluate --topology data-mesh --phase F1
+```
+
+Evaluates Data Mesh phase gates for the given architecture level, checking contract conformance and domain ownership.

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

@@ -0,0 +1,11 @@
+package evolith.topologies.datamesh
+
+violations[{"id":"DAM-R01","blocking":true,"message":"data-mesh.config.json must declare isDataProduct=true (DAM-R01)."}] { not input.satellite.dataMesh.isDataProduct }
+violations[{"id":"DAM-R02","blocking":true,"message":"data-mesh.config.json must declare hasDataContracts=true (DAM-R02)."}] { not input.satellite.dataMesh.hasDataContracts }
+violations[{"id":"DAM-R03","blocking":true,"message":"data-mesh.config.json must declare federatedGovernance=true (DAM-R03)."}] { not input.satellite.dataMesh.federatedGovernance }
+violations[{"id":"DAM-R04","blocking":true,"message":"All data products must declare lineage tracking; data-mesh.config.json must declare hasLineageTracking=true (DAM-R04)."}] { not input.satellite.dataMesh.hasLineageTracking }
+violations[{"id":"DAM-R05","blocking":true,"message":"data-mesh.config.json must declare hasRetentionPolicy=true with an explicit retention window per dataset (DAM-R05)."}] { not input.satellite.dataMesh.hasRetentionPolicy }
+violations[{"id":"DAM-R06","blocking":true,"message":"All consumers must register explicit consumption contracts; data-mesh.config.json must declare hasConsumptionContracts=true (DAM-R06)."}] { not input.satellite.dataMesh.hasConsumptionContracts }
+violations[{"id":"DAM-R07","blocking":false,"message":"Each data product must declare measurable quality SLOs; data-mesh.config.json must declare hasDataQualitySLO=true (DAM-R07)."}] { not input.satellite.dataMesh.hasDataQualitySLO }
+violations[{"id":"DAM-R08","blocking":false,"message":"Data contract schema changes must maintain backward compatibility; data-mesh.config.json must declare hasBackwardCompatibleContracts=true (DAM-R08)."}] { not input.satellite.dataMesh.hasBackwardCompatibleContracts }
+violations[{"id":"DAM-R09","blocking":false,"message":"All data products should register in a central data catalog; data-mesh.config.json should declare hasDiscoveryRegistration=true (DAM-R09)."}] { not input.satellite.dataMesh.hasDiscoveryRegistration }

package/rulesets/topologies/data-mesh/data-mesh.rules.json

@@ -0,0 +1,100 @@
+{
+  "$schema": "../../../../../rulesets/schema/ruleset-standard.schema.json",
+  "$id": "https://evolith.dev/rulesets/topologies/data-mesh.rules.json",
+  "title": "Data Mesh Topology Rules",
+  "description": "Architectural rules for the Data Mesh topology.",
+  "version": "1.1.0",
+  "effectiveDate": "2026-06-22",
+  "rules": [
+    {
+      "id": "DAM-R01",
+      "severity": "MUST",
+      "category": "data-mesh-config",
+      "title": "Data Product Designation",
+      "description": "A Data Mesh satellite MUST provide data-mesh.config.json and declare isDataProduct=true.",
+      "rationale": "Explicit data product designation enforces domain ownership of analytical data. Without this declaration, analytical datasets remain in an undefined ownership state that prevents federated governance and makes data discoverability impossible.",
+      "validationQuery": "Verify data-mesh.config.json exists and isDataProduct is set to true. Confirm a data product owner is registered in the domain catalog.",
+      "blocking": true
+    },
+    {
+      "id": "DAM-R02",
+      "severity": "MUST",
+      "category": "data-mesh-contracts",
+      "title": "Data Contracts",
+      "description": "data-mesh.config.json MUST declare hasDataContracts=true.",
+      "rationale": "Data contracts define the schema, SLOs, and behavioral guarantees a data product offers to consumers. Without them, downstream consumers face silent schema breaks and undefined freshness expectations.",
+      "validationQuery": "Verify data-mesh.config.json declares hasDataContracts=true. Confirm a contract document (e.g., DataContract YAML or JSON) exists and is versioned alongside the data product.",
+      "blocking": true
+    },
+    {
+      "id": "DAM-R03",
+      "severity": "MUST",
+      "category": "data-mesh-governance",
+      "title": "Federated Governance",
+      "description": "data-mesh.config.json MUST declare federatedGovernance=true.",
+      "rationale": "Federated computational governance is a foundational Data Mesh principle. Without it, each domain applies inconsistent policies for access, retention, and quality, defeating the purpose of domain-driven data ownership.",
+      "validationQuery": "Verify data-mesh.config.json declares federatedGovernance=true. Confirm the domain subscribes to the global governance platform (e.g., data catalog registration, policy engine enrollment).",
+      "blocking": true
+    },
+    {
+      "id": "DAM-R04",
+      "severity": "MUST",
+      "category": "data-lineage",
+      "title": "Data Product Lineage Tracking",
+      "description": "All Data Mesh products MUST declare hasLineageTracking=true and provide end-to-end lineage metadata from source to consumption.",
+      "rationale": "Without lineage, data engineers cannot trace the root cause of data quality issues, regulatory auditors cannot verify data provenance, and consumers cannot assess data trustworthiness. Lineage tracking is foundational for GDPR data impact assessments and incident response.",
+      "validationQuery": "Verify data-mesh.config.json declares hasLineageTracking=true. Confirm lineage metadata is emitted to a central lineage store (e.g., OpenLineage events or Marquez integration) at each transformation step.",
+      "blocking": true
+    },
+    {
+      "id": "DAM-R05",
+      "severity": "MUST",
+      "category": "retention",
+      "title": "Retention Policy on Data Products",
+      "description": "data-mesh.config.json MUST declare hasRetentionPolicy=true with an explicit retention window per dataset.",
+      "rationale": "Unmanaged analytical data accumulates indefinitely, violating GDPR right-to-erasure SLAs and creating unbounded storage costs. Explicit retention policies also define the historical window available for replay and backfill operations.",
+      "validationQuery": "Verify data-mesh.config.json declares hasRetentionPolicy=true. Confirm each dataset partition has an explicit retention duration defined in storage configuration (e.g., S3 lifecycle rules, BigQuery table expiry, or equivalent).",
+      "blocking": true
+    },
+    {
+      "id": "DAM-R06",
+      "severity": "MUST",
+      "category": "consumption-contracts",
+      "title": "Explicit Consumption Contracts",
+      "description": "All data product consumers MUST register explicit consumption contracts (hasConsumptionContracts=true), declaring the fields, freshness SLO, and volume expectations they depend on.",
+      "rationale": "Without registered consumption contracts, producers cannot assess the impact of schema or SLO changes on downstream consumers. Explicit contracts enable impact analysis before breaking changes are deployed and establish clear SLA responsibilities.",
+      "validationQuery": "Verify data-mesh.config.json declares hasConsumptionContracts=true. Confirm consumer contracts are registered in the data catalog and linked to data product versions.",
+      "blocking": true
+    },
+    {
+      "id": "DAM-R07",
+      "severity": "MUST",
+      "category": "observability",
+      "title": "Data Quality SLO Declaration",
+      "description": "Each data product MUST declare measurable data quality SLOs (hasDataQualitySLO=true): completeness, freshness, validity, and uniqueness targets.",
+      "rationale": "Undeclared data quality leaves consumers unable to make trust decisions about a dataset. SLO declarations force domain teams to define observable targets and enable automated quality gate failures when metrics degrade.",
+      "validationQuery": "Verify data-mesh.config.json declares hasDataQualitySLO=true. Confirm quality metrics (completeness %, freshness lag, validity rate, uniqueness rate) are emitted to the observability platform and alerts are configured per SLO threshold.",
+      "blocking": false
+    },
+    {
+      "id": "DAM-R08",
+      "severity": "MUST",
+      "category": "schema-evolution",
+      "title": "Data Contract Backward Compatibility",
+      "description": "All data product schema changes MUST maintain backward compatibility (hasBackwardCompatibleContracts=true). Breaking changes require a new versioned data product.",
+      "rationale": "Consumers of analytical data products evolve on independent deployment cycles. A breaking schema change — renaming a column, changing a type, removing a field — silently breaks downstream pipelines that cannot be updated in lockstep. Backward compatibility enforcement prevents uncoordinated breakage.",
+      "validationQuery": "Verify data-mesh.config.json declares hasBackwardCompatibleContracts=true. Validate that schema changes pass backward-compatibility checks in CI (e.g., schema registry diff, dbt schema change detection, or equivalent).",
+      "blocking": false
+    },
+    {
+      "id": "DAM-R09",
+      "severity": "SHOULD",
+      "category": "discovery",
+      "title": "Data Product Discoverability Registration",
+      "description": "All data products SHOULD register in a central data catalog (hasDiscoveryRegistration=true) with owner, description, schema, SLO, and consumption instructions.",
+      "rationale": "Without central registration, data products are invisible to potential consumers across domains. Discovery is a core Data Mesh principle: the data platform must surface products so teams can self-serve without ad-hoc communication with domain teams.",
+      "validationQuery": "Verify data-mesh.config.json declares hasDiscoveryRegistration=true. Confirm the data product record exists in the central catalog with all mandatory metadata fields populated (owner, schema link, SLO, access instructions).",
+      "blocking": false
+    }
+  ]
+}