# Propuesta técnica — Plataforma Kynda ## Diagnóstico del build actual y plan de reconstrucción **Preparado por:** [Tu nombre] **Fecha:** 23/07/2026 · **Versión:** v1 **Base del análisis:** deck corporativo v28, inspección del tenant en producción (`easyfairs.bekynda.com`), esquema Supabase (`supabase_kynda.sql`, 31 tablas) y capturas del panel de administración. --- ## 0. Resumen ejecutivo El build actual **no es un prototipo flojo**. Hay un MVP en producción (Next.js + Supabase + Vercel) con un **modelo de datos sólido y bien normalizado**: multi-tenant, control de roles, formularios dinámicos, definición de KPIs por fórmula, evidencias con EXIF/GPS, cadena/pulsera y consentimiento GDPR. Quien lo modeló sabía lo que hacía. Por eso, mi recomendación tras el diagnóstico es **evolucionar y refactorizar, no reconstruir desde cero.** Tirar esto destruiría trabajo bueno y reintroduciría riesgo. Los dos dolores que señala el cliente tienen causa concreta y localizable: 1. **IA / auditoría / CSRD.** La verificación "por IA" hoy es **manual**: las evidencias las aprueba Kynda Ops a mano (David/Violeta Kynda). Y los **KPIs de impacto se teclean a mano** en el panel. Eso rompe la promesa "no proof, no impact" y hace que los números **no sean auditables**. El esquema ya prevé la IA (`ai_review_run`) y los KPIs por fórmula (`action_kpi_def.formula`), pero **no están conectados**. 2. **Producto / UX.** El editor de campaña es un formulario de 10 secciones sobre una tabla `campaign` de ~50 columnas; el **embudo de activación (invitaciones) está vacío**; y hay desajustes de nomenclatura (jornada vs. action) que confunden a producto y a quien programa. **El plan en una línea:** una **Fase 0** de auditoría técnica (RLS, seguridad, GDPR, coste de IA) para cerrar alcance; después reconstruir por capas priorizando lo que hace creíble al producto (verificación real + KPIs calculados), luego el reporting audit-grade, y por último Enterprise. --- ## 1. Qué hay construido hoy **Superficies** - **Panel de empresa (web):** Inicio, Campañas, Catálogo, Validación, Impacto e informes, Participantes, Comunicaciones. Multi-tenant por subdominio (`easyfairs.bekynda.com`). - **App de empleado (web/PWA):** login, alta, recuperación y entrada por código de **pulsera** (`/c/enter`). - **Piloto real:** Easyfairs, campaña "Banco de Alimentos Verano 2026" (3 jornadas, 28 inscritos, **30 evidencias validadas**, 16.845 kg, 1.203 beneficiarios declarados). **Stack** - Front: **Next.js (App Router)** desplegado en **Vercel**. - Backend: **Supabase** (Postgres + Auth + Storage). 31 tablas. **Modelo de datos (por dominio)** - *Tenancy e identidad:* `brand`, `brand_plan`, `app_user`, `role`, `brand_membership`, `portal_allowlist`, `invitation`. - *Catálogo / plantillas:* `campaign_blueprint`, `blueprint_action`, `blueprint_action_field`, `field_option`, `action_kpi_def`. - *Campañas y acciones:* `campaign`, `action` (= jornada), `action_enrollment`, `action_execution`. - *Evidencia y validación:* `evidence`, `evidence_media`, `validation`, `ai_review_run`. - *Amplificación:* `generated_content`, `share_event`. - *Cadena / pulsera:* `chain_token`, `chain`, `chain_link`. - *Cumplimiento y operación:* `esrs_disclosure`, `sdg_goal`, `user_consent`, `notification`, `audit_log`, `ong`. --- ## 2. Lo que está bien (y hay que conservar) - **Multitenancy limpio:** `brand` + `brand_membership` + `role` con RBAC real (SUPERADMIN, OPS, BRAND_ADMIN, BRAND_MARKETING, BRAND_ESG, USER) y roles con ámbito GLOBAL/BRAND. `brand_id` está denormalizado en casi todas las tablas → preparado para RLS por tenant. - **Catálogo con formularios dinámicos tipados:** `blueprint_action_field` define campos con tipo (INT/FLOAT/ENUM/BOOL/TEXT/TIME), min/max, `suspicious_threshold`, `ui_hint` y dependencias entre campos. Es un form-builder serio. - **KPIs por fórmula:** `action_kpi_def` (formula, unit, aggregation SUM/COUNT/AVG/MAX, visibility). La intención de calcular impacto de forma reproducible está en el diseño. - **Máquinas de estado bien pensadas:** `action_execution` (STARTED → EVIDENCE_SUBMITTED → IN_VALIDATION → APPROVED/REJECTED/FRAUD_BLOCKED) y `evidence` con reintentos (`attempt_no`, `max_retries`) y estado de fraude. - **Materia prima para verificación automática:** `evidence_media` guarda `checksum`, `taken_at`, `gps_lat/lng`; `action` guarda `location_lat/lng`. Todo lo necesario para geofence + timestamp + dedup ya se captura. - **Cadena/pulsera modelada completa:** `chain_token` (código físico/digital) → `chain` → `chain_link` (hasta 6 posiciones). El "impact chain" del deck está a nivel de datos. - **GDPR de base:** `user_consent` (con IP, user-agent y versión), `retention_days`, `deleted_at`, tombstoning de media. - **Referencias normativas:** `esrs_disclosure` y `sdg_goal` como tablas de referencia. --- ## 3. Lo que falla (mapeado a los dolores del cliente) ### 3.1 IA / auditoría / CSRD - **La verificación es manual.** En la pestaña Evidencias, las 30 validaciones las firmaron David/Violeta Kynda a mano. `validation.kind = AUTO` existe pero no se usa, y `ai_review_run` no aparece en uso. Resultado: no escala (imposible con Enterprise de 10.000 empleados) y no es el diferenciador que vende el deck. - **Los KPIs se teclean a mano.** La pestaña Impacto son inputs que rellena el admin (kilos, lotes, personas beneficiarias, valor económico). Los titulares (16.845 kg, 1.203 personas) los **introduce la empresa** → no son auditables. `action_kpi_def.formula` + `action.results` existen para calcularlos desde la evidencia, pero no se computan. - **No hay nada "audit-grade".** El reporting es dashboards + "Exportar a Excel". Cero hash, sello de tiempo, trazabilidad por evidencia o XBRL. `audit_log` es una tabla mutable normal, no un registro a prueba de manipulación. La visión del deck (SHA-256, ledger, `audit.kynda.io`, ESEF) **no está construida**. ### 3.2 Producto / UX - **Embudo de activación roto.** El Home muestra "0% de 0 invitados" y Comunicaciones tiene 0 invitaciones; el alta se hizo por signup público y el sistema de invitaciones (`invitation`) no se usó ni alimenta el funnel. La métrica del Home queda confusa. - **`campaign` es una mega-tabla** (~50 columnas, con `objectives`, `evidence_config`, `social_config`, `enterprise_config`, `kpi_defs` como jsonb). Se traduce en un editor gigante difícil de mantener y validar, y **duplica** lo que ya vive en los blueprints (`kpi_defs` vs. `action_kpi_def`; `evidence_config` vs. `blueprint_action_field`). Falta una única fuente de verdad. - **Nomenclatura confusa.** "Jornada" (UI) = `action` (BD); conviven `blueprint_action` (tipo de tarea) y `action` (sesión concreta). Dos conceptos "action" distintos despistan a producto y al equipo. - **Datos de prueba en producción:** gmails personales ("Violeta Prueba", "Jorge Registro"…) mezclados con empleados reales de easyfairs.com. ### 3.3 Riesgos que hay que verificar sí o sí (Fase 0) - **RLS.** El dump es solo esquema, sin políticas. Toda la seguridad multi-tenant depende de que RLS por `brand_id` esté activada y bien hecha. Una fuga de datos entre marcas sería crítica. **Hay que confirmarlo antes que nada.** - **GDPR en la práctica.** Verificar que retención, borrado y consentimiento se aplican de verdad (fotos de personas + GPS + UE). - **Storage.** Políticas de acceso a `evidence_media` (privado por brand, URLs firmadas). --- ## 4. Veredicto: refactorizar, no reconstruir El modelo de datos es sano y anticipa casi todo lo que hace falta. Los problemas están en la **capa de aplicación**: pipelines que el esquema prevé pero que no están conectados (verificación, KPIs), UX del editor y del funnel, y la mega-tabla `campaign`. Reconstruir la base de datos tiraría trabajo bueno y volvería a introducir riesgo sin resolver el dolor real. **Por tanto: evolucionar + refactors quirúrgicos**, no un rebuild. Los refactors que sí haría dentro de esa evolución: 1. **Conectar los pipelines que el esquema ya anticipa** (verificación automática → `ai_review_run`; KPIs calculados → `action.results`). 2. **Definir la fuente de verdad blueprint ↔ campaign** y aligerar la mega-tabla `campaign` (sacar config a tablas/estructuras claras). 3. **Alinear nomenclatura** (jornada/sesión/acción) entre producto, UI y BD. Esta recomendación se confirma en Fase 0 una vez vea RLS, repo y coste de IA. --- ## 5. Arquitectura objetivo - **Front:** seguir con Next.js (App Router) en Vercel. App de empleado como **PWA instalable** (cámara, geolocalización, push) — o móvil nativo si el cliente lo exige; se decide en Fase 0. Panel admin web. - **Backend:** Supabase (Postgres + Auth + Storage + **Edge Functions** + Realtime), con **RLS por brand** como línea de defensa principal. - **Motor de verificación:** worker/Edge Function con cola. `evidence` SUBMITTED → checks deterministas → visión multimodal → `ai_review_run` → auto-aprobación o cola humana. - **Motor de KPIs/impacto:** computa desde `evidence.input_data` aprobada usando `action_kpi_def.formula` + aggregation → `action.results` y roll-up a campaña, trazable a la evidencia fuente. - **Reporting/auditoría:** capa append-only con hash encadenado + sello de tiempo por evidencia y decisión; export CSRD/ESRS (CSV/JSON primero, XBRL/ESEF después). - **Integraciones:** notificaciones (push/email vía `notification`), calendario (ICS), social asistido (`generated_content` + `share_event`), pulsera (`chain_*`), y SSO/HRIS en Enterprise. --- ## 6. Deep-dive 1 — Motor de verificación (el diferenciador) Pipeline por capas, de barato a caro: 1. **Checks deterministas** (en Edge Function, sin coste de IA): - *Geofence:* distancia entre `evidence_media.gps` y `action.location_lat/lng` ≤ radio. - *Tiempo:* `evidence_media.taken_at` dentro de `[action.starts_at, ends_at]` + margen. - *Metadatos:* EXIF presente y coherente; descartar capturas de pantalla. - *Dedup:* `checksum` contra media previa (de la persona, de la campaña y global). - *Campos:* `input_data` contra min/max/`suspicious_threshold` de `blueprint_action_field`. 2. **Visión multimodal** (solo para lo que pasa los filtros baratos): ¿la escena coincide con la acción/campaña? ¿la actividad es plausible? ¿hay contenido inseguro o PII de terceros? → escribe `ai_review_run` (result AUTHENTIC/FRAUD/UNCLEAR/CONTENT_VIOLATION, confidence). Modelo recomendado: multimodal tipo Claude. 3. **Triaje / decisión:** - AUTHENTIC con alta confianza + checks OK → **auto-aprobación** (`validation.kind = AUTO`). - UNCLEAR / FRAUD / checks fallidos → **cola humana** (`validation.kind = MANUAL`, priorizada por `sla_deadline`). Kynda Ops pasa de validar el 100% a revisar solo el ~10% dudoso. - NEEDS_CLARIFICATION → se pide reintento (`attempt_no`). - **Antifraude:** reutilización de imágenes, EXIF manipulado, GPS incoherente, ráfagas de envíos imposibles. - **Trazabilidad:** cada decisión (auto o humana) firma el hash de la evidencia + el resultado → es la base del audit-grade de la Fase 2. - **Coste:** modelar el coste de inferencia por evidencia en Fase 0; los filtros deterministas mantienen barata la mayoría de casos. **Nota de responsabilidad:** hay que fijar umbrales y dejar la revisión humana para los casos límite, porque un falso positivo que acabe en un informe CSRD auditado es un problema legal. El diseño anterior lo contempla. --- ## 7. Deep-dive 2 — Impacto auditable y CSRD - **KPIs calculados, no tecleados.** Cada `action_kpi_def.formula` se evalúa sobre el `input_data` de evidencias **aprobadas** → agrega (SUM/COUNT/AVG/MAX) → `action.results` y roll-up a campaña. Se elimina el tecleo de titulares (salvo override explícito y auditado). - **Trazabilidad de punta a punta.** Cada KPI enlaza a las evidencias que lo componen; cada evidencia a su media + validación + (si aplica) `ai_review_run`. - **ESRS/ODS.** `campaign.esrs_disclosures` + `ods_tags` ya mapean, y el catálogo trae tags por blueprint. La lógica regulatoria (qué acción cuenta para qué datapoint) la valida el cliente, que es experto ESG; nosotros ponemos el motor y el mapa de datos. - **Audit-grade (Fase 2).** Log append-only con hash encadenado (`prev_hash`) + sello de tiempo (RFC 3161) por evidencia y decisión; vista de auditor de solo lectura; export ESRS. XBRL/ESEF y `audit.kynda.io` como fase posterior. **Sin blockchain** salvo exigencia explícita del cliente: un log hash-encadenado con sello de tiempo cubre "audit-grade" sin esa complejidad. - **"Personas beneficiadas".** Hoy es una equivalencia tecleada (1.203). Hay que definir su metodología (factor por lote/kg) y documentarla, o etiquetarla claramente como estimación. Un auditor preguntará de dónde sale ese número. --- ## 8. Deep-dive 3 — Producto / UX - **Reparar el bucle de activación:** invitar (`invitation`) → onboarding → explorar → inscribirse (`action_enrollment`) → ejecutar (`action_execution`) → subir evidencia → verificar → amplificar. Arreglar el funnel y las métricas del Home. - **Rediseñar el editor de campaña:** partir el mega-formulario en pasos con una única fuente de verdad (heredar del blueprint, override explícito), reduciendo los jsonb sueltos. - **Design system de marca:** tokens (periwinkle, lima, salmón, rosa, navy), accesibilidad e i18n (es/en desde el inicio). - **App de empleado:** foco en el flujo apuntarse → hacer → verificar → compartir, con cámara, geolocalización, push y recordatorios. --- ## 9. Roadmap y estimación (orientativa; se cierra en Fase 0) Asumiendo un equipo pequeño (1–2 devs). Los rangos se afinan tras la auditoría. | Fase | Contenido | Duración orientativa | |------|-----------|----------------------| | **0 — Auditoría técnica** | RLS/seguridad, GDPR, calidad de código front/back, coste de IA, PWA vs. nativo. Entregable: informe + backlog priorizado + estimación cerrada. | 1–2 semanas | | **1 — Núcleo creíble** | Motor de verificación (deterministas + visión + triaje humano), KPIs calculados y trazables, reparación del bucle de activación y del editor de campaña, limpieza de datos. | ~6–10 semanas | | **2 — Audit-grade + amplificación + pulsera** | Log hash-encadenado + sello de tiempo + vista de auditor + export ESRS; contenido social asistido; activación de cadena/pulsera. | ~6–10 semanas | | **3 — Enterprise** | SSO/SAML, onboarding vía HRIS, XBRL/ESEF, multi-marca a escala, hardening de rendimiento y costes. | ~8–12 semanas | --- ## 10. Riesgos y decisiones abiertas - **RLS / seguridad multi-tenant** (verificar de inmediato en Fase 0). - **Coste y latencia** de la verificación por IA (modelar). - **Responsabilidad** ante un falso positivo que llegue a un informe CSRD → umbrales + revisión humana + trazabilidad. - **Metodología** de "personas beneficiadas" y equivalencias económicas (defendibles ante auditor). - **Alcance real** de pulsera y de amplificación social (auto-post vs. asistido). - **PWA vs. nativo** para la app de empleado. - **Propiedad del mapeo regulatorio ESRS** (lo aporta el cliente). --- ## 11. Qué necesito para cerrar la Fase 0 - Acceso de **solo lectura al repo** (front + back), o export del código. - Acceso al **proyecto Supabase** (rol Developer) para ver RLS/policies, Storage y Edge Functions — no la cuenta owner. - Si es posible, un rato de **traspaso con quien montó esto**.