@evolith/core-domain 1.0.1 → 1.0.3

package/rulesets/topologies/data-mesh/openapi/openapi.yaml

@@ -1,186 +0,0 @@
-openapi: "3.1.0"
-info:
-  title: "Data Mesh Topology — Core API Surface"
-  version: "0.1.0"
-  description: >
-    REST API surface specific to the Data Mesh topology.
-    Describes endpoints exposed by the Core API for querying,
-    inspecting, and validating Data Mesh topology instances.
-servers:
-  - url: "https://api.evolith.dev/v1"
-    description: "Evolith Core API (production)"
-paths:
-  /topologies/{id}:
-    get:
-      tags: [Topologies]
-      summary: "Retrieve Data Mesh topology information"
-      description: >
-        Returns the full topology record for Data Mesh, including
-        dimension, status, version, governance metadata, and corpus
-        artifact references (rulesets, OPA policies, ADRs, guidance).
-      operationId: "getDataMeshTopology"
-      parameters:
-        - name: id
-          in: path
-          required: true
-          schema:
-            type: string
-            pattern: "^data-mesh$"
-            example: "data-mesh"
-      responses:
-        "200":
-          description: "Successful response with Data Mesh topology data"
-          content:
-            application/json:
-              schema:
-                $ref: "#/components/schemas/EnvelopeTopology"
-        "404":
-          description: "Topology not found"
-  /topologies/{id}/manifest:
-    get:
-      tags: [Topologies]
-      summary: "Get Data Mesh topology manifest"
-      description: >
-        Returns the full topology manifest for Data Mesh, with
-        artifact references, corpus configuration, and business
-        boundary declaration.
-      operationId: "getDataMeshManifest"
-      parameters:
-        - name: id
-          in: path
-          required: true
-          schema:
-            type: string
-            pattern: "^data-mesh$"
-      responses:
-        "200":
-          description: "Successful response with Data Mesh manifest"
-          content:
-            application/json:
-              schema:
-                $ref: "#/components/schemas/EnvelopeManifest"
-  /topologies/{id}/validate:
-    post:
-      tags: [Topologies]
-      summary: "Validate Data Mesh topology rules"
-      description: >
-        Executes all applicable rulesets and OPA policies for Data Mesh
-        against a submitted configuration, returning pass/fail per gate.
-      operationId: "validateDataMeshTopology"
-      parameters:
-        - name: id
-          in: path
-          required: true
-          schema:
-            type: string
-            pattern: "^data-mesh$"
-      requestBody:
-        required: true
-        content:
-          application/json:
-            schema:
-              $ref: "#/components/schemas/ValidationRequest"
-      responses:
-        "200":
-          description: "Validation results"
-          content:
-            application/json:
-              schema:
-                $ref: "#/components/schemas/EnvelopeValidation"
-components:
-  schemas:
-    Envelope:
-      type: object
-      properties:
-        success:
-          type: boolean
-        data: {}
-        meta:
-          type: object
-          properties:
-            context:
-              type: string
-            timing:
-              type: number
-            schemaVersion:
-              type: string
-              pattern: "^\\d+\\.\\d+\\.\\d+$"
-          required: [context, timing, schemaVersion]
-      required: [success, data, meta]
-    EnvelopeTopology:
-      allOf:
-        - $ref: "#/components/schemas/Envelope"
-        - type: object
-          properties:
-            data:
-              $ref: "#/components/schemas/TopologyRecord"
-    EnvelopeManifest:
-      allOf:
-        - $ref: "#/components/schemas/Envelope"
-        - type: object
-          properties:
-            data:
-              $ref: "#/components/schemas/TopologyManifest"
-    EnvelopeValidation:
-      allOf:
-        - $ref: "#/components/schemas/Envelope"
-        - type: object
-          properties:
-            data:
-              $ref: "#/components/schemas/ValidationResult"
-    TopologyRecord:
-      type: object
-      properties:
-        id:
-          type: string
-          example: "data-mesh"
-        name:
-          type: string
-          example: "Data Mesh"
-        dimension:
-          type: string
-          example: "data"
-        status:
-          type: string
-          enum: [accepted, draft, deprecated]
-        version:
-          type: string
-          example: "0.1.0"
-    TopologyManifest:
-      type: object
-      properties:
-        apiVersion:
-          type: string
-          example: "evolith.dev/topology/v1"
-        kind:
-          type: string
-          example: "TopologyManifest"
-        metadata:
-          type: object
-        spec:
-          type: object
-    ValidationRequest:
-      type: object
-      properties:
-        config:
-          type: object
-          description: "Configuration to validate against topology rules"
-      required: [config]
-    ValidationResult:
-      type: object
-      properties:
-        passed:
-          type: boolean
-        gates:
-          type: array
-          items:
-            type: object
-            properties:
-              gate:
-                type: string
-              passed:
-                type: boolean
-              evidence:
-                type: array
-                items:
-                  type: string

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

@@ -1,63 +0,0 @@
-# Guía de Operaciones de Malla de Datos
-
-> **Navegación Bilingüe:** [English](./operations.md) | [Español](./operations.es.md)
-
-**Propietario:** Arquitectura de Datos
-**Topología:** Malla de Datos
-**Reglas Relacionadas:** DAM-R01, DAM-R03
-**ADRs Relacionados:** ADR-0084
-
-## Propósito
-
-Esta guía define los procedimientos operativos para gestionar los productos de datos a lo largo de su ciclo de vida, desde la designación de dominio hasta la deprecación. Establece el modelo de propiedad de dominio, la gobernanza de la plataforma de autoservicio y el monitoreo de salud de los flujos de datos necesarios para operaciones sostenibles de la malla.
-
-## Modelo de Propiedad de Dominio
-
-Cada dominio es responsable de sus productos de datos de extremo a extremo. Los propietarios de productos de datos de dominio son responsables de la calidad, disponibilidad y cumplimiento de contratos con consumidores. Las transferencias de propiedad requieren una entrega formal con SLAs actualizados y notificación a consumidores.
-
-Los equipos de dominio deben designar un líder de producto de datos que sirva como punto de contacto principal para todos los consumidores. El líder es responsable del esquema, los SLAs de calidad y las decisiones de ciclo de vida del producto.
-
-## Ciclo de Vida del Producto de Datos
-
-Los productos de datos siguen un ciclo de vida de cuatro etapas: borrador, publicado, deprecado y archivado. Cada etapa tiene criterios de entrada y salida explícitos definidos en DAM-R01. Los productos en estado de borrador no son descubribles a través de la plataforma de autoservicio. Los productos deprecados deben mantener compatibilidad backward por un período mínimo de transición.
-
-### Definiciones de Etapa
-
-- **Borrador:** Prototipo interno del dominio. Sin SLA. No descubrible en el catálogo de la plataforma.
-- **Publicado:** Listo para consumidores. SLA activo. Registrado en el índice de descubrimiento.
-- **Deprecado:** Programado para eliminación. Compatibilidad backward mantenida según DAM-R08. Consumidores notificados.
-- **Archivado:** Solo lectura. No se aceptan nuevos consumidores. Política de retención según DAM-R05.
-
-## Gobernanza de la Plataforma de Autoservicio
-
-La plataforma de autoservicio es la interfaz principal para el registro, descubrimiento y consumo de productos de datos. Los equipos de plataforma proporcionan la infraestructura; los equipos de dominio operan sus productos a través de ella.
-
-La gobernanza de la plataforma requiere que todos los metadatos del producto de datos — propiedad, esquema, SLAs, clasificación — estén registrados antes de la publicación. Los productos no registrados no deben aparecer en el índice de descubrimiento.
-
-## Monitoreo de Flujos de Datos
-
-Los equipos de dominio son responsables de monitorear sus flujos de ingesta y la frescura de las salidas. La plataforma proporciona paneles de observabilidad centralizados; los equipos configuran sus propios umbrales de alerta alineados con los SLAs del producto.
-
-Dimensiones clave de monitoreo: latencia del flujo, frescura de salida, conteo de registros, deriva de esquema y tasas de error. Todas las métricas deben exponerse a través de la plataforma de autoservicio para visibilidad interdominio.
-
-## Verificaciones de Salud del Producto
-
-Las verificaciones de salud automatizadas se ejecutan en un horario configurable. El estado de salud se publica en el índice de descubrimiento y es consumido por productos dependientes. Los criterios de verificación incluyen frescura, completitud, unicidad y validez de datos según DAM-R07.
-
-Los productos que fallan las verificaciones se marcan en el catálogo de la plataforma y activan notificaciones a consumidores dentro de la ventana de alerta configurada.
-
-## Comandos de Validación
-
-```bash
-# Verificar registro del producto
-node .harness/scripts/ci/01-validate-docs.mjs --target data-mesh
-
-# Verificar paridad bilingüe
-node .harness/scripts/ci/04-check-bilingual-parity.mjs
-
-# Ejecutar panel de cobertura
-node .harness/scripts/coverage-dashboard.mjs --area data-mesh
-```
-
----
-[Volver al Perfil de Malla de Datos](./README.es.md)

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

@@ -1,63 +0,0 @@
-# Data Mesh — Operations Guide
-
-> **Bilingual Navigation:** [English](./operations.md) | [Español](./operations.es.md)
-
-**Owner:** Data Architecture
-**Topology:** Data Mesh
-**Related Rules:** DAM-R01, DAM-R03
-**Related ADRs:** ADR-0084
-
-## Purpose
-
-This guide defines operational procedures for managing data products across their lifecycle, from domain designation through deprecation. It establishes the domain ownership model, self-serve platform governance, and pipeline health monitoring required for sustainable mesh operations.
-
-## Domain Ownership Model
-
-Each domain owns its data products end-to-end. Domain data product owners are accountable for quality, availability, and consumer contract compliance. Ownership transfers require formal handoff with updated SLAs and consumer notification.
-
-Domain teams must designate a data product lead who serves as the primary point of contact for all consumers. The lead owns the product's schema, quality SLOs, and lifecycle decisions.
-
-## Data Product Lifecycle
-
-Data products follow a four-stage lifecycle: draft, published, deprecated, and archived. Each stage has explicit entry and exit criteria defined in DAM-R01. Products in draft status are not discoverable through the self-serve platform. Deprecated products must maintain backward compatibility for a minimum transition period.
-
-### Stage Definitions
-
-- **Draft:** Internal domain prototype. No SLA. Not discoverable via platform catalog.
-- **Published:** Consumer-ready. SLA active. Registered in discovery index.
-- **Deprecated:** Scheduled for removal. Backward compatibility maintained per DAM-R08. Consumers notified.
-- **Archived:** Read-only. No new consumers accepted. Retention policy per DAM-R05.
-
-## Self-Serve Platform Governance
-
-The self-serve platform is the primary interface for data product registration, discovery, and consumption. Platform teams provide the infrastructure; domain teams operate their products through it.
-
-Platform governance requires that all data product metadata — ownership, schema, SLAs, classification — is registered before publication. Unregistered products must not appear in the discovery index.
-
-## Pipeline Monitoring
-
-Domain teams are responsible for monitoring their ingestion pipelines and output freshness. Platform provides centralized observability dashboards; teams configure their own alerting thresholds aligned to product SLOs.
-
-Key monitoring dimensions: pipeline latency, output freshness, record counts, schema drift, and error rates. All metrics must be exposed through the self-serve platform for cross-domain visibility.
-
-## Product Health Checks
-
-Automated health checks run on a configurable schedule. Health status is published to the discovery index and consumed by dependent products. Health check criteria include data freshness, completeness, uniqueness, and validity as defined in DAM-R07.
-
-Products failing health checks are flagged in the platform catalog and trigger consumer notifications within the configured alert window.
-
-## Validation Commands
-
-```bash
-# Verify product registration
-node .harness/scripts/ci/01-validate-docs.mjs --target data-mesh
-
-# Check bilingual parity
-node .harness/scripts/ci/04-check-bilingual-parity.mjs
-
-# Run coverage dashboard
-node .harness/scripts/coverage-dashboard.mjs --area data-mesh
-```
-
----
-[Back to Data Mesh Profile](./README.md)

package/rulesets/topologies/data-mesh/parity-fixtures/compliant.json

@@ -1,18 +0,0 @@
-{
-  "input": {
-    "satellite": {
-      "dataMesh": {
-        "isDataProduct": true,
-        "hasDataContracts": true,
-        "federatedGovernance": true,
-        "hasLineageTracking": true,
-        "hasRetentionPolicy": true,
-        "hasConsumptionContracts": true,
-        "hasDataQualitySLO": true,
-        "hasBackwardCompatibleContracts": true,
-        "hasDiscoveryRegistration": true
-      }
-    }
-  },
-  "expectedNative": []
-}

package/rulesets/topologies/data-mesh/parity-fixtures/violation.json

@@ -1,21 +0,0 @@
-{
-  "input": {
-    "satellite": {
-      "dataMesh": {
-        "isDataProduct": false,
-        "hasDataContracts": true,
-        "federatedGovernance": true,
-        "hasLineageTracking": false,
-        "hasRetentionPolicy": true,
-        "hasConsumptionContracts": true,
-        "hasDataQualitySLO": true,
-        "hasBackwardCompatibleContracts": true,
-        "hasDiscoveryRegistration": true
-      }
-    }
-  },
-  "expectedNative": [
-    { "ruleId": "DAM-R01", "severity": "error", "file": null },
-    { "ruleId": "DAM-R04", "severity": "error", "file": null }
-  ]
-}

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

@@ -1,67 +0,0 @@
-# Guía de Patrones de Malla de Datos
-
-> **Navegación Bilingüe:** [English](./patterns.md) | [Español](./patterns.es.md)
-
-**Propietario:** Arquitectura de Datos
-**Topología:** Malla de Datos
-**Reglas Relacionadas:** DAM-R01, DAM-R02, DAM-R06
-**ADRs Relacionados:** ADR-0084, ADR-0079
-
-## Propósito
-
-Esta guía describe los patrones arquitectónicos centrales que definen la topología de malla de datos. Cada patrón aborda una preocupación específica — diseño de producto, gobernanza, contratos, plataforma, descubrimiento o propiedad. Estos patrones son componibles con topologías de módulos distribuidos, microservicios, event-driven, serverless y agentic-ai.
-
-## Datos como Producto
-
-Los productos de datos son entidades arquitectónicas de primera clase con propiedad explícita, SLAs, esquemas y gestión de ciclo de vida. Los productos no son extracciones o vistas ad-hoc — son activos gestionados gobernados por DAM-R01.
-
-Cada producto expone una interfaz estable definida por su esquema. Los cambios siguen los requisitos de compatibilidad backward de DAM-R08. Los productos deben ser descubribles, direccionables y confiables.
-
-## Gobernanza Federada
-
-La gobernanza opera en dos niveles: definición central de políticas y aplicación a nivel de dominio. El órgano central de gobernanza establece estándares — clasificación, seguridad, cumplimiento — mientras los dominios los implementan dentro de los límites de sus productos.
-
-Este patrón previene cuellos de botella de gobernanza mientras mantiene la consistencia organizacional. Las excepciones de gobernanza requieren aprobación formal y se rastrean como excepciones en el registro de gobernanza según DAM-R03.
-
-## Contratos de Datos (DAM-R02)
-
-Los contratos de datos son acuerdos formales entre productores y consumidores. Un contrato especifica el esquema, garantías de calidad, SLAs de frescura y políticas de acceso para un producto de datos. Los contratos se versionan y están sujetos a reglas de compatibilidad backward.
-
-Los contratos deben ser legibles por máquina y ejecutados por la plataforma. Los acuerdos manuales no son contratos válidos. La plataforma de autoservicio media todas las operaciones del ciclo de vida de contratos.
-
-## Contratos de Consumo (DAM-R06)
-
-Los contratos de consumo definen cómo los consumidores acceden y usan los productos de datos. Especifican patrones de consulta, alcance de acceso y restricciones de uso. Los contratos de consumo complementan los contratos de producción documentando obligaciones del lado del consumidor.
-
-Los consumidores deben registrar sus contratos de consumo en la plataforma. Los consumidores no registrados pueden ser bloqueados del acceso a productos hasta el registro del contrato.
-
-## Plataforma de Autoservicio
-
-La plataforma de autoservicio es la columna vertebral operativa de la malla. Proporciona descubrimiento, registro, ejecución de políticas, monitoreo y gestión de contratos. Los equipos de plataforma son dueños de la infraestructura; los equipos de dominio operan a través de ella.
-
-Las capacidades de la plataforma deben incluir: registro de productos, gestión de esquemas, configuración de políticas de acceso, monitoreo de salud, rastreo de linaje y incorporación de consumidores.
-
-## Descubrimiento y Registro (DAM-R09)
-
-Todos los productos de datos publicados deben registrarse en el índice de descubrimiento. El registro incluye propiedad, esquema, clasificación, SLAs e información de contacto. Los productos no registrados son invisibles para los consumidores y no deben usarse para intercambio de datos interdominio.
-
-El registro de descubrimiento es un requisito previo para la publicación. Los productos en estado de borrador se excluyen del índice de descubrimiento según DAM-R01.
-
-## Propiedad de Dominio
-
-Cada dominio de negocio es dueño de sus productos de datos. La propiedad incluye diseño, implementación, operación y deprecación. Los equipos de dominio son responsables de la calidad del producto, satisfacción del consumidor y cumplimiento.
-
-Las transferencias de propiedad requieren procedimientos formales de entrega que incluyen renegociación de SLAs, notificación a consumidores y actualización de metadatos de la plataforma. La propiedad no es compartida — cada producto tiene exactamente un dominio propietario.
-
-## Comandos de Validación
-
-```bash
-# Verificar cumplimiento de patrones
-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/patterns.md

@@ -1,67 +0,0 @@
-# Data Mesh — Patterns Guide
-
-> **Bilingual Navigation:** [English](./patterns.md) | [Español](./patterns.es.md)
-
-**Owner:** Data Architecture
-**Topology:** Data Mesh
-**Related Rules:** DAM-R01, DAM-R02, DAM-R06
-**Related ADRs:** ADR-0084, ADR-0079
-
-## Purpose
-
-This guide describes the core architectural patterns that define data mesh topology. Each pattern addresses a specific concern — product design, governance, contracts, platform, discovery, or ownership. These patterns are composable with distributed-modules, microservices, event-driven, serverless, and agentic-ai topologies.
-
-## Data as a Product
-
-Data products are first-class architectural entities with explicit ownership, SLAs, schemas, and lifecycle management. Products are not ad-hoc extracts or views — they are managed assets governed by DAM-R01.
-
-Each product exposes a stable interface defined by its schema. Changes follow the backward-compatibility requirements of DAM-R08. Products must be discoverable, addressable, and trustworthy.
-
-## Federated Governance
-
-Governance operates at two levels: central policy definition and domain-level enforcement. The central governance body establishes standards — classification, security, compliance — while domains implement them within their product boundaries.
-
-This pattern prevents governance bottlenecks while maintaining organizational consistency. Governance exceptions require formal approval and are tracked as exceptions in the governance registry per DAM-R03.
-
-## Data Contracts (DAM-R02)
-
-Data contracts are formal agreements between producers and consumers. A contract specifies the schema, quality guarantees, freshness SLAs, and access policies for a data product. Contracts are versioned and subject to backward-compatibility rules.
-
-Contracts must be machine-readable and enforced by the platform. Manual agreements are not valid contracts. The self-serve platform mediates all contract lifecycle operations.
-
-## Consumption Contracts (DAM-R06)
-
-Consumption contracts define how consumers access and use data products. They specify query patterns, access scope, and usage constraints. Consumption contracts complement production contracts by documenting consumer-side obligations.
-
-Consumers must register their consumption contracts in the platform. Unregistered consumers may be blocked from accessing products pending contract registration.
-
-## Self-Serve Platform
-
-The self-serve platform is the operational backbone of the mesh. It provides discovery, registration, policy enforcement, monitoring, and contract management. Platform teams own the infrastructure; domain teams operate through it.
-
-Platform capabilities must include: product registration, schema management, access policy configuration, health monitoring, lineage tracking, and consumer onboarding.
-
-## Discovery and Registration (DAM-R09)
-
-All published data products must be registered in the discovery index. Registration includes ownership, schema, classification, SLAs, and contact information. Unregistered products are invisible to consumers and must not be used for cross-domain data sharing.
-
-Discovery registration is a prerequisite for publication. Products in draft status are excluded from the discovery index per DAM-R01.
-
-## Domain Ownership
-
-Each business domain owns its data products. Ownership includes design, implementation, operation, and deprecation. Domain teams are accountable for product quality, consumer satisfaction, and compliance.
-
-Ownership transfers require formal handoff procedures including SLA renegotiation, consumer notification, and platform metadata updates. Ownership is not shared — each product has exactly one owning domain.
-
-## Validation Commands
-
-```bash
-# Verify pattern compliance
-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/resilience.es.md

@@ -1,64 +0,0 @@
-# Guía de Resiliencia de Malla de Datos
-
-> **Navegación Bilingüe:** [English](./resilience.md) | [Español](./resilience.es.md)
-
-**Propietario:** Arquitectura de Datos
-**Topología:** Malla de Datos
-**Reglas Relacionadas:** DAM-R07
-**ADRs Relacionados:** ADR-0084
-
-## Propósito
-
-Esta guía define las prácticas de resiliencia para los productos de datos en una topología de malla. Cubre gestión de SLAs, estrategias de respaldo, caché, monitoreo de disponibilidad, recuperación de fallos de flujos y garantías de frescura. La resiliencia es de propiedad del dominio pero validada por la plataforma.
-
-## SLAs de Productos de Datos
-
-Cada producto de datos publicado debe declarar un SLA que cubra disponibilidad, frescura y completitud. Los SLAs se registran en la plataforma de autoservicio y se utilizan para verificaciones de salud automatizadas según DAM-R07.
-
-Niveles de SLA: crítico (99.9% disponibilidad, <1h frescura), estándar (99% disponibilidad, <4h frescura), mejor esfuerzo (sin garantía de disponibilidad, frescura al mejor esfuerzo). Los consumidores seleccionan productos según la alineación de SLA con sus requisitos.
-
-## Consultas de Respaldo
-
-Los consumidores deben definir estrategias de respaldo para fallos de productos aguas arriba. Las estrategias incluyen: leer de capturas en caché, cambiar a productos de menor fidelidad o pausar procesamiento dependiente. La configuración de respaldo es parte del contrato del consumidor.
-
-Los equipos de dominio deben documentar el comportamiento de respaldo en los READMEs de productos y ponerlo disponible a través de la plataforma de autoservicio para orquestación automatizada.
-
-## Caché
-
-La plataforma proporciona caché incorporado para productos de acceso frecuente. Los dominios pueden configurar políticas de caché por producto según requisitos de frescura y patrones de acceso. La invalidación de caché se activa por fallos en verificaciones de salud o cambios de esquema.
-
-Los datos en caché deben respetar los mismos controles de acceso que el producto fuente. El TTL de caché se alinea con el SLA de frescura del producto.
-
-## Monitoreo de Disponibilidad
-
-La infraestructura de la plataforma proporciona monitoreo de disponibilidad centralizado para todos los productos publicados. Los equipos de dominio configuran umbrales de alerta alineados con sus SLAs declarados. Las métricas de disponibilidad se publican en el índice de descubrimiento para consumo de los consumidores.
-
-El monitoreo cubre: accesibilidad de extremos, tasas de éxito de consultas, percentiles de latencia y categorización de errores. Las interrupciones se clasifican y escalan por nivel de severidad.
-
-## Recuperación de Fallos de Flujos
-
-Los equipos de dominio definen procedimientos de recuperación para sus flujos de ingesta. Los procedimientos de recuperación deben documentarse y probarse. La plataforma proporciona patrones de circuit-breaker para consumidores downstream cuando fallan flujos aguas arriba.
-
-Los procedimientos de recuperación deben incluir: lógica de reintento automático, colas de cartas muertas para registros no procesables, disparadores de intervención manual y validación posterior a la recuperación. Todas las acciones de recuperación se registran para fines de auditoría.
-
-## Garantías de Frescura
-
-Los SLAs de frescura especifican el retraso máximo aceptable entre actualizaciones de datos fuente y disponibilidad del producto. La plataforma rastrea métricas de frescura contra SLAs declarados. Los consumidores pueden consultar el estado de frescura a través de la plataforma de autoservicio.
-
-Los productos que incumplen SLAs de frescura se marcan automáticamente. Los consumidores reciben notificaciones según sus preferencias de alerta configuradas. Las violaciones de frescura activan el proceso de respuesta a incidentes de calidad.
-
-## Comandos de Validación
-
-```bash
-# Validar declaraciones de SLA
-node .harness/scripts/ci/01-validate-docs.mjs --target data-mesh
-
-# Verificar paridad bilingüe
-node .harness/scripts/ci/04-check-bilingual-parity.mjs
-
-# Ejecutar verificación de cobertura
-node .harness/scripts/coverage-dashboard.mjs --area data-mesh
-```
-
----
-[Volver al Perfil de Malla de Datos](./README.es.md)

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

@@ -1,64 +0,0 @@
-# Data Mesh — Resilience Guide
-
-> **Bilingual Navigation:** [English](./resilience.md) | [Español](./resilience.es.md)
-
-**Owner:** Data Architecture
-**Topology:** Data Mesh
-**Related Rules:** DAM-R07
-**Related ADRs:** ADR-0084
-
-## Purpose
-
-This guide defines resilience practices for data products in a mesh topology. It covers SLA management, fallback strategies, caching, availability monitoring, pipeline failure recovery, and freshness guarantees. Resilience is domain-owned but platform-validated.
-
-## Data Product SLAs
-
-Each published data product must declare an SLA covering availability, freshness, and completeness. SLAs are registered in the self-serve platform and used for automated health checks per DAM-R07.
-
-SLA tiers: critical (99.9% availability, <1h freshness), standard (99% availability, <4h freshness), best-effort (no availability guarantee, freshness best-effort). Consumers select products based on SLA alignment with their requirements.
-
-## Fallback Queries
-
-Consumers must define fallback strategies for upstream product failures. Strategies include: reading from cached snapshots, switching to lower-fidelity products, or pausing dependent processing. Fallback configuration is part of the consumer contract.
-
-Domain teams must document fallback behavior in product READMEs and make it available through the self-serve platform for automated orchestration.
-
-## Caching
-
-The platform provides built-in caching for frequently accessed products. Domains may configure cache policies per product based on freshness requirements and access patterns. Cache invalidation is triggered by product health check failures or schema changes.
-
-Cached data must respect the same access controls as the source product. Cache TTL aligns with the product's freshness SLA.
-
-## Availability Monitoring
-
-Platform infrastructure provides centralized availability monitoring for all published products. Domain teams configure alerting thresholds aligned to their declared SLAs. Availability metrics are published to the discovery index for consumer consumption.
-
-Monitoring covers: endpoint reachability, query success rates, latency percentiles, and error categorization. Outages are classified and escalated per severity tier.
-
-## Pipeline Failure Recovery
-
-Domain teams define recovery procedures for their ingestion pipelines. Recovery procedures must be documented and tested. The platform provides circuit-breaker patterns for downstream consumers when upstream pipelines fail.
-
-Recovery procedures must include: automatic retry logic, dead-letter queues for unprocessable records, manual intervention triggers, and post-recovery validation. All recovery actions are logged for audit purposes.
-
-## Freshness Guarantees
-
-Freshness SLAs specify the maximum acceptable delay between source data updates and product availability. The platform tracks freshness metrics against declared SLAs. Consumers can query freshness status through the self-serve platform.
-
-Products failing freshness SLAs are flagged automatically. Consumers receive notifications per their configured alerting preferences. Freshness violations trigger the quality incident response process.
-
-## Validation Commands
-
-```bash
-# Validate SLA declarations
-node .harness/scripts/ci/01-validate-docs.mjs --target data-mesh
-
-# Check bilingual parity
-node .harness/scripts/ci/04-check-bilingual-parity.mjs
-
-# Run coverage check
-node .harness/scripts/coverage-dashboard.mjs --area data-mesh
-```
-
----
-[Back to Data Mesh Profile](./README.md)