Los 55 servicios: qué resuelve cada uno y cómo se construye.

Relevamiento de cómo funciona la organización un día cualquiera: procesos, quién hace qué, y dónde se corta la información entre áreas.

Cómo se construye. Modelado entidad-relación antes de la primera pantalla: el dominio se escribe como schema de Prisma sobre PostgreSQL y las vistas se derivan de ahí. El modelo tiene que contener lo que la operación ya hace y ningún formulario genérico contempla —paquetes, bonificaciones, ajustes, cobros heredados—, porque un esquema que no los tiene los empuja al campo de observaciones, y de ahí no salen nunca más como dato.

Tareas duplicadas, fugas de margen, controles que dependen de una sola persona, cobros que nunca se registraron y restricciones que bloquean el crecimiento.

Cómo se construye. El problema se busca en los datos y no en la entrevista: scripts que recorren el histórico completo con consultas SQL y encuentran lo que el sistema anterior no contabilizaba. Lo más común es plata que sí entró: cobros anotados a mano en el texto libre de una nota, que nunca llegaron a la tabla de pagos y por lo tanto no figuran en ningún balance.

Unificación de los registros hoy dispersos en planillas, papel, mensajería y sistemas heredados, en una sola base consultable y con un único registro por entidad.

Cómo se construye. Extracción, saneamiento e importación con upsert por identificador de origen en vez de insert: la migración se puede correr de nuevo cuantas veces haga falta y converge al mismo estado, sin duplicar ni pisar lo que se cargó a mano en el medio. Es la diferencia entre una carga que hay que hacer bien de una sola vez y una que se puede repetir mientras la empresa sigue trabajando.

Rentabilidad real por servicio, por producto y por profesional. Estacionalidad, ausentismo, recurrencia, abandono y ticket promedio.

Cómo se construye. Las métricas se calculan por agregación SQL sobre el libro de operaciones —pagos, gastos y ajustes fechados—, nunca sobre una tabla de resumen que alguien actualiza. No hay proceso nocturno que pueda quedar viejo: el número se deriva en el momento de la consulta, así que no existe el estado en que el tablero y la base dicen cosas distintas.

Cada falla operativa traducida a pesos por mes, para priorizar por retorno esperado y no por urgencia percibida.

Cómo se construye. Medidor de costo por operación: una fila por etapa, un solo INSERT, y escrito para que un fallo del medidor nunca tumbe la operación que está midiendo. La regla dura es que un precio desconocido se guarda como NULL y jamás como cero, porque un cero se suma y baja el total sin que nadie note que falta un dato.

Proyección de la operación a doce meses en dos escenarios: sin intervención, y con las correcciones que salieron del diagnóstico. Apta para presentar ante socios o entidades financieras.

Cómo se construye. Modelos de valuación y simulación escritos a mano, no una planilla: flujos descontados con crecimiento que decae, valor terminal, tres escenarios y matriz de sensibilidad, más Monte Carlo con semilla fija para que el mismo supuesto dé siempre el mismo número. El informe declara qué porcentaje del valor viene del valor terminal, que es la forma de ver si la proyección se apoya en la operación o en un supuesto lejano.

Las variables críticas en una sola pantalla: facturación, márgenes, cobranzas, caja y clientes activos.

Cómo se construye. Dos superficies separadas a propósito: una pantalla en vivo del día, que se revalida sola y se mira de paso, y un panel histórico para el análisis, con rangos y comparaciones. Van separadas porque tienen cadencias de consulta distintas, y mezclarlas hace que la consulta pesada del análisis frene la del mostrador.

Proyección de ingresos contra egresos, margen de contribución, y asignación correcta de los costos fijos y los variables.

Cómo se construye. Ingresos y gastos como transacciones fechadas, agregadas por período con consultas por rango. El deudor no es un campo: es la diferencia entre lo facturado y lo cobrado, calculada al consultar. Un saldo guardado como campo se desincroniza en el primer pago que entre por otra vía; derivado, no puede.

Revisión periódica del tablero con la dirección: análisis de desvíos y definición de las acciones del período siguiente sobre datos medidos.

Cómo se construye. Trabajo de análisis sobre el sistema ya instalado, sin desarrollo nuevo: se leen los indicadores del período contra los del anterior y se separa el desvío estacional del desvío real. No hay reunión fija en el calendario: se convoca cuando un indicador se sale del rango que se acordó.

Un solo sistema para toda la empresa: clientes, compras, ventas, inventario, caja y reportes, modelado sobre los procesos que la empresa ya tiene y no sobre un esquema genérico.

Cómo se construye. Next.js con App Router y TypeScript en modo estricto, Prisma como capa de acceso y PostgreSQL como base. El dominio se modela primero y las pantallas se derivan del modelo, no al revés. Las escrituras van por server actions con su control de permisos adentro, así que no queda un endpoint abierto que la interfaz simplemente no muestra.

Ficha única del cliente, historial completo, avisos automáticos por inactividad y seguimiento de oportunidades.

Cómo se construye. El aviso por inactividad se calcula del historial real con una ventana de tiempo, no de una bandera que alguien marca, y el ciclo se reinicia solo cuando el cliente vuelve. Los umbrales son configurables por público y hay un espaciado mínimo entre piezas, para que dos reglas distintas no le escriban a la misma persona el mismo día.

Reservas de profesionales, salas o equipos desde la web, con confirmación automática, sobreturnos y medición de ausentismo.

Cómo se construye. Agenda y calendario como dos vistas del mismo modelo, no dos módulos que hay que mantener en sincronía. La integración con plataformas externas de agendamiento entra por webhook con firma verificada. Y hacia afuera se publica como feed iCalendar según la RFC 5545, con identificador estable, zona horaria y alarmas, autenticado por token en la propia dirección porque los clientes de calendario no envían cookies.

Emisión de comprobantes fiscales desde el sistema, cuenta corriente, presupuestos, señas y conciliación.

Cómo se construye. SDK oficial de AFIP integrado al modelo de facturación, con la emisión del lado del servidor y detrás de un permiso propio, para que no cualquier rol facture. El comprobante queda vinculado al pago y a la cuenta corriente en la misma operación, de modo que no exista una factura emitida que la cuenta del cliente no refleje.

Inventario que descuenta insumos por consumo real, con alertas de reposición, costeo y control de vencimientos.

Cómo se construye. El stock no es un campo editable: es la suma de los movimientos registrados producto por producto, cada uno con su motivo y su fecha. Por eso cualquier saldo se puede explicar hacia atrás hasta el movimiento que lo produjo, y un descuadre pasa a ser una pregunta con respuesta en vez de un número que alguien corrige a mano.

Evoluciones, imágenes, consentimientos informados, control de accesos y cumplimiento de la normativa de retención.

Cómo se construye. Auditoría append-only escrita contra la Ley 26.529 art. 13 (integridad, inalterabilidad y control de modificación de campos) y la Ley 25.326 de datos sensibles. No existe función para borrar ni editar una traza —no es una restricción de permisos, es que el código no lo implementa—, y el identificador del paciente se guarda sin clave foránea a propósito, con el motivo escrito en el schema, para que la traza sobreviva al borrado del paciente. El borrado, además, no es un DELETE: es una solicitud que otro rol aprueba.

Ingresos y egresos por centro de costo, liquidación por profesional, caja diaria y control de deudores.

Cómo se construye. El reparto se deriva por consulta de las operaciones cerradas del período, no de una planilla paralela que alguien mantiene, y queda detrás de una capacidad de permiso propia: después de la historia clínica es el dato más sensible del sistema.

Cada persona accede únicamente a lo que su función requiere, y toda acción queda asentada en un registro central de auditoría.

Cómo se construye. Matriz de capacidades nombradas resuelta por una función pura en un solo archivo, no permisos dispersos por las pantallas. Del lado de la base, políticas de acceso por fila con patrón lectura-del-dueño y escritura reservada al rol de servicio, así que ni una consulta mal escrita devuelve la fila de otra cuenta. La sesión va en una cookie firmada con HMAC-SHA256 por Web Crypto, y en producción el middleware falla cerrado: si falta el secreto o es demasiado corto, la aplicación no arranca.

Extracción de los datos del sistema heredado sin interrumpir la operación, e integración con el software que la empresa no va a reemplazar.

Cómo se construye. Dos caminos separados a propósito: una carga inicial destructiva que exige una bandera explícita y cuyo mensaje de error indica cuál script usar en su lugar, y un sincronizador que hace upsert y no borra nada. Cuando el sistema de origen no expone API, se integra igual: acceso por sesión autenticada contra la misma interfaz que usa una persona, con limitador de tráfico compartido por todas las cuentas y parsers que distinguen un resultado vacío legítimo de un cambio en el HTML de origen, para alertar en vez de reportar todo en orden con datos viejos.

Sitios de empresa y páginas de campaña: carga rápida, comportamiento correcto en cualquier resolución y la propuesta expresada sin ambigüedad.

Cómo se construye. HTML y CSS escritos a mano, sin framework y sin constructor: con los estilos dentro del documento, la página entera resuelve en una sola descarga. El canonical, el sitemap, el robots y los datos estructurados JSON-LD salen del mismo módulo, de modo que no puedan contradecirse entre sí. El canonical único y centralizado responde a una razón medible: el dominio raíz y el www sirven lo mismo, y sin él el buscador lo lee como contenido duplicado y reparte la autoridad entre las dos direcciones en vez de acumularla en una.

Aplicación que se instala en el dispositivo desde el navegador y opera sin conexión, sin trámite de tienda ni proceso de aprobación.

Cómo se construye. Manifiesto con iconos maskable y service worker escrito a mano —no generado por un plugin— para controlar qué se cachea y cuándo se invalida. Pantallas de arranque de iOS en los nueve tamaños que pide Safari, y fuentes servidas desde el propio dominio, así la aplicación abre sin conexión y sin depender de un tercero.

La misma aplicación en iPhone y Android, compartiendo la lógica con la plataforma web.

Cómo se construye. El estado de la aplicación se modela como un documento serializable, sin un solo término de GPU ni de plataforma, para que después lo interprete Core Image en iOS y su equivalente en Android sin reescribir la lógica. La primera entrega puede salir como PWA instalable en iPhone y en Android, sin trámite de tienda ni espera de aprobación. El alta en App Store y en Play Console se presupuesta aparte y con su plazo, porque no es trabajo de programación: revisión de Apple, ficha y capturas por tamaño de dispositivo, pistas de prueba cerrada y distribución interna por TestFlight.

Acceso privado donde el cliente consulta su cuenta, descarga comprobantes y resuelve sus propios trámites sin intervención del equipo.

Cómo se construye. El acceso se valida en el servidor contra la base, no escondiendo botones: las direcciones privadas viven server-only y el endpoint verifica el estado antes de redirigir, así que la dirección nunca llega al navegador de quien no corresponde. Del lado de la base, políticas de acceso por fila, para que el aislamiento entre cuentas no dependa de que cada consulta esté bien escrita.

Cobro en línea construido para que ninguna venta se pierda por una falla del proveedor y ningún pago se acredite dos veces.

Cómo se construye. Cada pasarela va con su propio esquema de verificación de firma —HMAC-SHA256 con template, HMAC-SHA512 sobre el cuerpo con las claves ordenadas recursivamente, o verificación contra la API oficial con los headers de transmisión— y la comparación es en tiempo constante, para no filtrar el secreto por el tiempo de respuesta. El webhook no confía en lo que le llega: re-consulta el pago contra la API del proveedor. Y la acreditación es idempotente por flip atómico —UPDATE ... WHERE status='pending' RETURNING id—, así que de dos avisos simultáneos solo uno gana y el cliente se cobra una vez. Sin la variable de entorno, la pasarela arranca en modo de prueba en lugar de cobrar de verdad.

Eliminación de la fricción que hace que una visita se retire sin consultar.

Cómo se construye. Se instrumenta la profundidad de recorrido y los eventos de salida, y se corrige sobre ese dato y no sobre opinión. El rendimiento se trabaja igual: se mide el hilo principal bloqueado, y lo que casi siempre lo bloquea son los propios scripts de medición, que se difieren con requestIdleCallback en vez de sacarlos.

Presencia en los resultados de búsqueda para los términos con los que se busca lo que la empresa vende, y control de cómo se presenta ahí.

Cómo se construye. SEO implementado por código y no por plugin. El sitemap se genera del catálogo real con frecuencia de cambio y prioridad por ruta, y excluye las páginas cerradas dejando el motivo escrito; el robots declara sus exclusiones. Seis generadores de JSON-LD cubren Organization, WebSite, Course con Offer y duración en ISO-8601, ItemList, BreadcrumbList y FAQPage. La metadata es dinámica por página, con canonical propio, Open Graph completo y max-image-preview en large. La imagen para compartir se genera en tiempo de ejecución, para no mantener a mano un PNG que se desactualiza.

Alta y mantenimiento de las fichas en mapas y directorios del rubro, para captar consultas por proximidad.

Cómo se construye. Trabajo de gestión, sin entregable de software: alta verificada, categorización, y datos de contacto, dirección y horarios idénticos a los del sitio, porque la discrepancia entre la ficha y el sitio es lo que degrada la posición.

Reactivación del cliente inactivo en el momento oportuno, con un tope de contactos por período.

Cómo se construye. Tres públicos definidos por comportamiento, con umbrales configurables y espaciado mínimo entre piezas para que dos reglas no le escriban a la misma persona el mismo día. El ciclo se reinicia solo si la persona vuelve. La idempotencia vive en la base y no en el código que envía, y hay un modo de prueba en seco que muestra a quién le tocaría antes de mandar un solo correo.

Origen del tráfico, punto exacto de abandono y recorrido previo a la compra, medidos y no supuestos.

Cómo se construye. La medición se sirve por proxy inverso desde el propio dominio: así los bloqueadores no la cortan y no hay que aflojar la política de seguridad de contenido para dejarla pasar. Va con doble diferido para no competir con el renderizado, y las conversiones se envían con el identificador de la transacción, que es lo que después permite conciliar lo que dice la plataforma de anuncios contra lo que dice la base.

Asistente que responde sobre la documentación de la empresa, sin capacidad de afirmar lo que no está en ella ni de comprometer condiciones.

Cómo se construye. Cascada multi-proveedor con respaldo, caché del contexto persistido en Redis entre invocaciones para no volver a pagar el mismo contexto en cada pregunta, filtro de intentos de manipulación previo al modelo, y límite de consumo en tres niveles —por usuario, por curso y un corte global de costo— porque una cuenta comprometida sin techo es una factura abierta.

Traspaso al sistema del trabajo de mover datos entre plataformas, rearmar el mismo reporte cada semana y enviar los mismos avisos.

Cómo se construye. Tareas programadas declaradas en la configuración del despliegue, autenticadas con un secreto y que fallan cerradas: sin el secreto devuelven error en vez de ejecutarse. La idempotencia se logra con ventanas de búsqueda exactas en la consulta y no con una tabla auxiliar de control, así que si el planificador dispara dos veces la misma tarea, el segundo disparo no encuentra nada que hacer.

Ingesta desde sistemas propios, APIs externas y registros oficiales, con normalización y control de calidad antes de que el dato quede disponible.

Cómo se construye. Cada dato viaja con su fuente y su fecha, exigido por tipos y no por convención. Si la fuente falla, el pipeline devuelve vacío para que la pantalla diga 'dato no disponible', nunca un valor de relleno; cuando hay varias fuentes, cascada que valida el resultado antes de aceptarlo. Los conectores a fuentes oficiales están auditados uno por uno por licencia, forma de acceso y estabilidad del endpoint, y lo descartado por motivo legal queda declarado con el motivo.

Consulta en lenguaje natural sobre contratos, manuales, historiales o normativa, con el documento exacto que respalda cada respuesta.

Cómo se construye. Búsqueda híbrida sobre PostgreSQL: brazo semántico con pgvector por distancia coseno más brazo léxico con tsvector, fusionados por RRF y reordenados por un reranker cross-encoder con presupuesto de tiempo, cortacircuito y degradación segura a orden por coseno si el reranker no llega. El índice es HNSW con hnsw.iterative_scan en relaxed_order y no en su valor por defecto: con el valor por defecto el brazo semántico se pierde entero en una parte de las consultas, sin error y sin log, que es la peor forma de fallar. Los embeddings son multilingües y llevan guardias contra el desajuste de dimensiones, una de ellas corriendo dentro del build del despliegue.

Borradores de escritos, respuestas e informes armados con la información verificada de la empresa, para que una persona los revise y firme.

Cómo se construye. El borrador se arma con las fuentes recuperadas y pasa por el verificador de citas antes de existir como documento. La exportación a DOCX cumple el reglamento del organismo que lo recibe hasta el detalle: A4 en twips exactos, márgenes, tipografía e interlineado reglamentarios, tomo, folio y matrícula. No es prolijidad: el incumplimiento del formato habilita la desestimación del escrito.

Imposibilidad técnica de que el sistema afirme algo que no esté respaldado por un documento de la empresa. Es la diferencia entre una herramienta que se usa y una que hay que revisar entera.

Cómo se construye. Un verificador bloqueante: si falla, la cascada se detiene antes del control de calidad y la salida final se limita a la lista blanca de citas que el verificador emitió. La capa determinística corre después del modelo, sobre el entregable, y puede bajar la conclusión pero nunca subirla. Y el verificador se revisa a sí mismo: toda objeción que cite un texto que ya no existe se descarta por revalidación determinística, porque una falla fantasma tiraba análisis enteros. El guard corre en las cinco superficies de salida y la paridad entre ellas se comprueba por código en la integración continua, no a ojo.

Seguimiento de competidores, regulación, precios y tendencias, con el enlace al documento original junto a cada dato.

Cómo se construye. Consumo directo de APIs oficiales —entre ellas la CFTC y el Federal Register— más fuentes públicas de conversación, con validación de la forma de cada respuesta contra un esquema antes de usarla. Los bloques del tablero se degradan de a uno: si una fuente cae, ese bloque dice que no hay dato y el resto sigue sirviendo, en vez de que la pantalla entera quede en blanco por una fuente.

Generación y distribución del informe periódico sin intervención, con el mismo criterio de cálculo en cada corrida.

Cómo se construye. El reporte se sintetiza de varias fuentes sobre el dato vivo, con revalidación programada en el servidor en lugar de una generación nocturna que puede amanecer vieja, y se exporta a un archivo publicable con las referencias numeradas y trazables hasta su origen.

Definición de qué se mide y de cuál es el valor que determina si el resultado fue el buscado, fijada antes de empezar.

Cómo se construye. Cada indicador se define contra lo que el sistema efectivamente puede calcular, y se escribe la consulta que lo produce antes de aceptarlo como meta. Un indicador que no sale del dato que ya existe no entra: es la forma de no terminar con un tablero que hay que llenar a mano.

Posición de la empresa frente a su competencia, y la secuencia de crecimiento que la operación puede sostener sin degradarse.

Cómo se construye. Trabajo de análisis y decisión, sin entregable de software. El insumo son los números del diagnóstico: capacidad instalada, margen por línea y costo de captación.

Sostenimiento del producto en el tiempo: lo pedido se incorpora, lo descartado queda registrado con su razón, y ninguna decisión cerrada se reabre sin un motivo nuevo.

Cómo se construye. Backlog con cuatro estados explícitos —pendiente, diferido a propósito, descartado con su razón, y en el radar— y un changelog fechado que vive separado del pendiente. La categoría de descartado con razón es la que evita que la misma discusión vuelva cada tres meses: la decisión y su motivo quedan escritos donde se los busca.

Formulación de qué distingue a la oferta, en una versión única que se sostiene igual en cada canal.

Cómo se construye. Trabajo de definición, sin entregable de software. El insumo sale del diagnóstico —qué resuelve la operación mejor que la alternativa disponible— y no de una sesión de ideas.

Qué canal conviene para cada línea, y cuál es el costo real de servir por cada uno.

Cómo se construye. Trabajo de análisis, sin entregable de software: costo de servir por canal —comisión, logística, atención y devoluciones— contrastado contra el margen de cada línea.

Recorrido del cliente etapa por etapa, con el punto exacto donde abandona.

Cómo se construye. El recorrido se mide con analítica instrumentada en la propia página —profundidad de scroll, eventos de salida, tiempo por sección— y se cruza contra lo que dice la base del sistema de gestión. Suponer el recorrido y medirlo dan resultados distintos, y el que sirve para decidir es el segundo.

Nombre y sistema de identidad para un proyecto nuevo o para una marca que necesita formalizarse.

Cómo se construye. La identidad se define contra lo que el producto realmente hace. Si el manual y el producto se contradicen, el que está mal es el manual. El sistema se baja a tokens —color, tipografía y medida— en el mismo repositorio del producto, de modo que la marca y lo que se ve en pantalla no puedan divergir con el tiempo.

Logotipo, paleta, tipografías y reglas de uso, aplicables tanto en pantalla como impresas.

Cómo se construye. Un solo bloque de variables CSS define el color, la tipografía y la escala, y no queda un valor hexadecimal suelto en el resto del documento. Hay un chequeo automático que lo verifica y falla si aparece uno. Así el sistema no se puede desarmar de a poco: para cambiar un color hay que cambiarlo en el único lugar donde está definido.

El documento que le permite a cualquier proveedor externo aplicar la marca sin romperla.

Cómo se construye. Se escribe después de que existe la primera pantalla aprobada, y describe lo que hay. Un manual escrito antes termina definiendo cosas que el producto después contradice. El entregable no es un PDF: son los tokens en código, los componentes con su tipado y su ejemplo de uso, las guías, y un kit interactivo donde el proveedor prueba la pieza antes de producirla.

Actualización de una identidad existente, conservando los elementos que el público ya reconoce.

Cómo se construye. Se conserva el símbolo —lo único que el público tiene memorizado— y se reconstruye el sistema alrededor: paleta, tipografía, escala y reglas de aplicación. Queda escrito qué cambió y por qué, que es lo que evita que el rediseño se vuelva a discutir en seis meses.

Aplicación de la marca a las piezas de uso diario: tarjetas, formularios, señalética, indumentaria y plantillas.

Cómo se construye. Piezas cerradas para producción, con las tramas, los archivos fuente editables y las especificaciones que el proveedor necesita para no volver a preguntar. Los archivos se entregan a nombre del cliente: cualquier imprenta los abre sin pedir permiso.

El concepto visual y narrativo de un lanzamiento o una campaña puntual.

Cómo se construye. Trabajo creativo por proyecto, sin entregable de software: concepto, guion visual, piezas por canal y las reglas de uso que impiden que la campaña contradiga a la identidad.

Memorias, informes de gestión, propuestas y catálogos con nivel de presentación para un directorio.

Cómo se construye. El documento se genera del dato en vez de maquetarse a mano, con referencias numeradas y trazables hasta la fuente y la fecha de cada número, y se exporta a un archivo publicable. Sirve igual para una memoria anual, un informe de gestión o un paper.

Definición de cómo habla la marca, sostenida igual en cada canal, incluido lo que responde un sistema automático.

Cómo se construye. El tono se escribe como reglas ejecutables y no como adjetivos: el prompt de sistema del asistente lleva reglas duras y explícitas, incluida la prohibición de prometer resultados y la forma exacta de responder cuando no sabe. Del lado humano, lo mismo: las plantillas de mensaje viven en el sistema y se editan ahí, no en el teléfono de cada persona.

Entrega del correo correcto en el momento correcto, con la configuración de dominio que lo deja en la bandeja de entrada y no en el correo no deseado.

Cómo se construye. Motor de envío con tres reintentos con espera creciente, interruptor de corte, y que nunca lanza excepción, porque los correos salen dentro de webhooks de pago: si el proveedor de mail falla, la compra igual se acredita. Render propio con HTML compatible con Gmail y Outlook más salida en texto plano, y remitente humano en lugar de un no-reply, con el motivo escrito. La autenticación del dominio —SPF, DKIM y DMARC— entra en el alcance del alta, porque sin eso el mejor contenido llega al correo no deseado.

Coordinación de la presencia publicitaria en medios tradicionales y canales masivos.

Cómo se construye. Trabajo de gestión y coordinación, sin entregable de software: pauta, negociación con el medio, adaptación de cada pieza al formato que exige, y control de que se emitió lo contratado.

Oferta, precio y posicionamiento de la competencia, y los segmentos que deja sin atender.

Cómo se construye. Se arma sobre registros públicos y oficiales, con la fuente al lado de cada número, y no sobre lo que la competencia dice de sí misma. La participación de mercado, por ejemplo, se calcula de los datos del organismo regulador y no del material comercial del competidor.

Demanda sin atender, cambios en el comportamiento de compra y segmentos con margen disponible.

Cómo se construye. Se cruzan varias fuentes independientes con ingesta programada, y cuando una no aportó se declara que no aportó, en vez de tapar el hueco con la que sí. Un informe que no distingue el dato ausente del dato en cero es un informe con el que no se puede decidir.

Disposición a pagar, volumen de demanda y percepción de la empresa frente al resto del mercado.

Cómo se construye. Clasificación de sentimiento validada contra un esquema con Zod antes de aceptar la salida, y el ítem que no se puede clasificar queda neutro en lugar de forzado a una categoría. El sesgo de cobertura se declara en el propio tablero: si la muestra es mayormente de un idioma o de un mercado, eso se rotula y no se presenta como si fuera global.