Cygnus · primera versión previstaV1 previstaCygnus 1.0 es una versión prevista, sujeta a criterios de aceptación, de una base de datos de grafos temporal y programable. El alcance que sigue es un plan de diseño y cualificación; ningún criterio de versión ni objetivo de rendimiento se presenta como alcanzado.
Estado: Cygnus 1.0 no ha sido aceptada ni publicada. Las capacidades incluidas, la seguridad, la documentación, la compatibilidad, el despliegue y la evidencia de recuperación deben superar todas las pruebas antes de una versión pública.
La versión prevista combina lenguaje, entorno de ejecución, almacenamiento y servicios bajo un único modelo semántico. Una implementación candidata no es una versión pública.
Lenguaje y ejecución tipados, almacenamiento transaccional de grafos y series temporales, autenticación y autorización en las rutas de almacenamiento, servicios HTTP/RPC y de streaming tipados, cliente TypeScript generado, descriptores de API y MCP.
Los siete perfiles de modalidad acotados que se detallan más abajo, recorrido de grafos, indexación geoespacial, recuperación de texto/BM25 y dispersa/densa, ventanas temporales, agregaciones (rollups) y suscripciones persistentes.
Una interfaz Explorer seleccionada, cinco patrones de aplicación congelados para gemelos, telemetría, registros de eventos, trayectorias geográficas y CRUD de recursos; núcleo LSP, cliente para VS Code y depuración headless acotada.
Trabajos y programaciones persistentes, observabilidad en un solo servidor, copia de seguridad, recuperación a un punto en el tiempo y restauración verificada; un contrato de chat acotado con cualificación de proveedores fijada en versiones exactas y una corrección controlada de forma independiente.
Orden de dependencias: núcleo → contratos de servicio y seguridad → datos temporales, espaciales y de recuperación → Explorer seleccionado y herramientas para agentes → operación en un solo servidor y chat acotado. Los datos y los servicios seguros preceden a la interfaz más amplia para agentes.
Son requisitos previstos para la primera versión, con sus propios criterios de conformidad y de seguridad; no se afirma que todas las interfaces estén disponibles hoy.
Operaciones HTTP/RPC y de streaming tipadas, flujos de cambios, clientes TypeScript generados y descripciones de servicio versionadas para su uso por API y MCP. Un servicio de archivos gestionados basado en Blob ofrecería directorios virtuales transaccionales y transferencias acotadas, sin análisis implícito ni acceso al sistema de archivos del host.
Una cola propia de decisiones y aprobaciones conservaría las decisiones humanas de referencia más allá de una sesión de agente. La propuesta de un agente y su evidencia se mantienen separadas del permiso para activarla.
La base nativa incluye etiquetas de idioma, contexto de presentación, identidad tipada de mensajes y catálogos, y un formateo acotado. El servidor y los clientes TypeScript generados deben coincidir en catálogos fijados; las configuraciones regionales de producción concretas y los periodos de soporte siguen abiertos.
El Explorer autenticado seleccionado abarca Visión general, Datos/grafo, Actividad/registros, Funciones/API/MCP, Acceso y la configuración cualificada de chat y proveedores. Su localización debe superar comprobaciones de argumentos tipados, escritura de derecha a izquierda (RTL), pseudolocalización, accesibilidad, traducciones hostiles y paridad entre servidor y cliente. El núcleo LSP, el cliente ligero para VS Code y el contrato de depuración headless acotada son obligatorios; la integración de un Debug Adapter Protocol en el editor se aplaza.
Los cinco patrones de aplicación congelados son entidad de gemelo, serie de telemetría, registro de eventos, trayectoria geográfica y CRUD de recursos. Un sistema general de UI declarativa o un entorno de ejecución del lenguaje en el navegador no forman parte de esta primera versión.
Son requisitos de arquitectura para la versión prevista, sujetos a la cualificación de conformidad y de seguridad.
El acceso bitemporal distingue el tiempo de validez de un hecho del momento en que entró en el sistema. Una respuesta «a fecha de» debería ser reproducible en ambos ejes, incluidas las correcciones posteriores.
Las transacciones estrictamente serializables con detección de conflictos lógicos de grano fino están pensadas para mantener en una misma época de commit los cambios de entidades, grafo, tiempo e índices transaccionales o recursos derivados declarados.
Las comprobaciones de acceso residen en las rutas de almacenamiento y ejecución, incluidos los recorridos de índices, los recorridos del grafo y las agregaciones. El descubrimiento es independiente del acceso de lectura; los recursos denegados no deben filtrarse a través de recuentos, errores o indicios de su existencia. La autorización de la búsqueda se aplica antes de la ordenación y de la selección top-k.
El efecto declarado de una función pública describe un comportamiento potencial; nunca concede permiso por sí mismo. El contenido recuperado y la salida del modelo siguen sin ser de confianza cuando un agente propone una acción con una herramienta.
Las fuentes almacenadas conservan un acceso acotado, descriptores versionados, clasificación, procedencia, conservación y autorización. El texto, los mosaicos o los embeddings derivados se versionan de forma explícita y nunca sustituyen sin aviso al original.
| Modalidad | Representación prevista en la primera versión | Fuera de lo que se afirma para la primera versión |
|---|---|---|
| Texto | Cadenas UTF-8 acotadas; UTF-8 de gran tamaño como blobs transmitidos en streaming o leídos por rangos; índice de texto/BM25 versionado por analizador. | Reparación universal de juegos de caracteres, normalización implícita que modifique la fuente o materialización ilimitada de cadenas. |
| Documentos | Bytes de origen de referencia con metadatos y procedencia; los derivados explícitos de texto y fragmentos pueden aportarse o generarse mediante un proveedor externo declarado. | Análisis universal de PDF y documentos ofimáticos, OCR silencioso o tratar el texto extraído como la fuente. |
| Imagen, audio y vídeo | Bytes de origen, metadatos multimedia y resumen criptográfico; ingesta acotada reanudable, streaming por rangos y derivados externos versionados de forma explícita. | Decodificadores o transcodificadores integrados, canal de vídeo nativo, miniaturas, extracción de fotogramas o similitud multimedia intrínseca. |
| Estado de series temporales | Acceso puntual, por lotes y por rangos, extensiones regulares/irregulares y resolución exacta; más adelante en la secuencia de entrega incluida, ventanas por tiempo de evento, marcas de agua (watermarks), agregaciones y suscripciones persistentes. | Varios eventos independientes en un mismo instante dentro de una sola serie; para eso, use un mapa de eventos. |
| SIG vectorial | Valores y entidades geográficas que tienen en cuenta el CRS, geometrías grandes transmitidas en streaming cuando sea necesario, predicados exactos y candidatos indexados con verificación exacta. | Ejecución espacial distribuida o un lenguaje de escape general compatible con PostGIS. |
| SIG ráster | Bytes de origen con descriptor ráster, acceso acotado por bytes o rangos y proyecciones externas declaradas de mosaicos o vistas generales. | Decodificación ráster integrada, reproyección nativa o generación de vistas generales, o acceso aleatorio garantizado a mosaicos desde formatos secuenciales. |
| Numéricos densos y dispersos | Arrays acotados y arrays dispersos; almacenamiento mínimo de tensores de coma flotante de forma fija para embeddings generados por proveedores. | Álgebra tensorial general, ejecución de modelos, ONNX, entrenamiento, cuantización o cálculo en dispositivos. |
Los formatos de intercambio concretos, los tipos de documentos y multimedia admitidos, los perfiles vectoriales y ráster, las versiones de proveedores y los entornos de prueba de seguridad siguen siendo decisiones de versión.
La topología de producción prevista es un servidor. Puede alojar varios clientes (tenants) con aislamiento y cuotas, pero su capacidad y su dominio de fallo siguen siendo un único nodo.
| Perfil | Posición prevista para la primera versión | Límite |
|---|---|---|
| Embebido | Incluido | Un proceso de aplicación con almacenamiento local; sin proceso de servidor independiente. |
| Desarrollo | Incluido | Arranque de proyecto vacío y modos de fuente explícitos. |
| Producción en un solo servidor | Incluido | Un nodo. Primero, durabilidad POSIX; la durabilidad en almacenamiento de objetos y el soporte de copias de seguridad forman parte del alcance de la versión. |
| Clúster | Excluido · perfil posterior | No se afirma particionado (sharding), replicación, recorrido distribuido ni conmutación por error. |
| Carga de trabajo aislada | Excluido | Sin perfil de despliegue para cargas de trabajo aisladas cualificado por separado. |
Las opciones de entorno de despliegue, como el centro de datos del cliente o una nube privada, son independientes de estos perfiles de entorno de ejecución.
El perfil de producción previsto combina trabajos y programaciones persistentes con evidencia operativa en un solo servidor. No afirma nada sobre clústeres, conmutación por error entre réplicas ni disponibilidad entre nodos.
Las copias de seguridad programadas completas e incrementales, la restauración verificada y la recuperación a un punto en el tiempo, la conservación/TTL y las retenciones legales son requisitos incluidos. Una copia de seguridad completada no demuestra que una aplicación y sus datos puedan restaurarse.
La observabilidad en producción y los objetivos de servicio declarados vincularían los incidentes con la aplicación y la versión afectadas. Solo las clases de corrección registradas y autorizadas de antemano pueden actuar dentro de su perfil acotado; una autorización caducada o revocada debe denegar la acción o escalarla.
Las decisiones de despliegue canario y de reversión siguen bajo control independiente. El agente que propone una reparación no puede aprobar la ampliación de su propia autoridad, cambiar sus criterios de aceptación ni activar a su sucesor.
El despliegue progresivo de esquemas, contratos y backend está previsto para el perfil de un solo servidor. Una ABI nativa de C estable y un límite supervisado de proveedores permiten integraciones declaradas sin añadir el registro abierto ni el host de componentes que llegarán más adelante.
La cualificación de la versión exige además recuperación ante fallos, cero pérdidas de commits confirmados y pruebas de restauración superadas en las condiciones declaradas. Los umbrales numéricos propuestos figuran más abajo como pruebas, no como resultados medidos ni niveles de servicio.
Son supuestos de carga de trabajo propuestos, pendientes de ratificación por parte de sus autores y de medición con socios de diseño. «Mundial» describe el objeto de estudio, no una ejecución distribuida.
| Dimensión | Carga de trabajo de referencia propuesta |
|---|---|
| Entidades del gemelo | 250 000 buques; 5000 puertos y terminales; 2 millones de unidades de carga |
| Ingesta de posiciones | 25 000 informes/s sostenidos; 100 000 informes/s en una ráfaga de 60 segundos |
| Conservación con plena fidelidad | 90 días; unos 194 000 millones de muestras y 2 TB comprimidos |
| Conservación submuestreada | Una muestra cada 5 minutos hasta 36 meses; unos 79 000 millones de muestras y 0,8 TB |
| Eventos y documentos | 5 millones de escalas portuarias, avisos y manifiestos al año |
| Embeddings | 768 dimensiones float32; unos 15 GB/año en bruto |
| Forma del grafo | Rutas de titularidad, fletamento y operador hasta profundidad 6; grado de salida medio de 4; nodos portuarios de hasta 100 000 aristas |
| Concurrencia interactiva | 200 personas y 50 clientes automáticos |
| Hardware y memoria | Clase de hardware de referencia propuesta de 32 vCPU; relación entre conjunto de datos y RAM de aproximadamente 24:1. La RAM, el fabricante y el modelo de almacenamiento no están especificados. |
La cifra de 25 000 informes/s sostenidos describe esta carga de trabajo de referencia. La cifra de 100 000 informes/s sostenidos de los criterios de aceptación es un criterio de versión propuesto más exigente; 80 000 informes/s en ese hardware es un umbral distinto, a partir del cual se revisaría el alcance.
Un cálculo teórico de diseño, con unos 10,3 bytes comprimidos por muestra, apunta a aproximadamente entre 1 y 2 billones de muestras y hasta 20 TiB por nodo. No es un resultado de capacidad medido.
≈10,3 bytes
comprimidos por muestra: la base del cálculo de diseño
1–2 billones
de muestras por nodo, aproximadamente, según el cálculo teórico de diseño
≤20 TiB
por nodo con esa densidad; no es un resultado de capacidad medido
10 TiB / 16 GiB
un caso de cualificación propuesto distinto: almacenamiento frente a RAM instalada
Un caso de cualificación propuesto distinto utiliza 10 TiB de almacenamiento con 16 GiB de RAM instalada para consultas acotadas puntuales, por rangos, por páginas, por muestras y por ventana de visualización. No significa que el corpus o un índice completo residan en memoria, ni que todas las consultas globales sean interactivas.
Con el criterio de versión más exigente de 100 000 informes/s, 90 días de muestras con plena fidelidad supondrían unos 0,78 billones de muestras y 8 TB. Doce meses supondrían unos 3,2 billones y 32 TB, más allá del punto de diseño propuesto para un solo nodo. Una conservación más larga requeriría submuestreo o un perfil de clúster posterior. La exportación completa, la ordenación global y la reconstrucción de índices completos siguen siendo tareas de streaming o de trabajos persistentes.
Antes de la 1.0, lo único garantizado es que los identificadores estables asignados nunca se reutilizan. Todos los demás compromisos para 1.x son intenciones de versión, y varios detalles siguen sin decidirse.
| Dimensión | Antes de la 1.0 | Comportamiento previsto en 1.x o decisión abierta |
|---|---|---|
| Lenguaje fuente | Sin promesa de compatibilidad 1.x antes de la 1.0. | La gramática de la 1.0 queda congelada; el código fuente aceptado por la 1.0 sigue siendo aceptado por las 1.x posteriores. |
| Descriptores y catálogo | Los identificadores estables de tipos, campos y demás identificadores asignados nunca se reutilizan. | Una 1.x posterior lee los descriptores escritos por versiones 1.x anteriores. |
| Bytecode y planes | Sin promesa general de compatibilidad. | Los planes físicos se reconstruyen al actualizar. Los trabajos persistentes fijan una referencia de ejecución; un entorno de ejecución más reciente la lee, la migra, la reproduce de forma explícita o la rechaza. Los puntos de control arbitrarios no son portables. |
| Decodificación del almacenamiento | Sin promesa general de compatibilidad. | Las versiones posteriores conservan los decodificadores de los bloques 1.x que sigan referenciados. |
| Escritura del almacenamiento | Sin promesa general de compatibilidad. | La lectura hacia atrás se declara por formato. No se promete la vuelta a una versión anterior. |
| Protocolo y API | Sin promesa general de compatibilidad. | Solo cambios aditivos dentro de 1.x; los cambios incompatibles requieren una nueva versión mayor del servicio. |
| Cliente generado | Sin promesa general de compatibilidad. | Un cliente generado para 1.x compila contra servidores 1.x posteriores. |
| Frontend declarativo | Sin promesa general de compatibilidad. | Los tipos de descriptores son aditivos dentro de 1.x. |
| Paquetes y componentes | Sin promesa general de compatibilidad. | Los decodificadores conservados, los bloqueos y determinadas interfaces de proveedores nativos se amplían de forma compatible. Un registro abierto y un host de componentes son trabajo posterior. |
| Actualización progresiva del clúster | No aplicable. | No aplicable: no hay perfil de clúster en la 1.0. |
| Copia de seguridad y restauración | Sin promesa general de compatibilidad. | Una 1.x posterior restaura copias de seguridad de 1.x anteriores e informa de un resultado de restauración verificado. |
| Configuración operativa | Sin promesa general de compatibilidad. | Solo cambios aditivos dentro de 1.x; para eliminar algo hace falta una versión de obsolescencia previa. |
| Adaptador de proveedor de IA | Sin promesa general de compatibilidad. | El esquema de chat portable y el protocolo de workers se amplían de forma compatible. Los artefactos de cada proveedor fijan sus propias versiones, direcciones y capacidades. No se presupone ningún modelo ni función de un fabricante. |
| Espacio de trabajo de agentes y MCP | Periodo de soporte pendiente de seleccionar. | Las direcciones de versión, la negociación y el comportamiento ante fallos requieren una decisión de versión. |
| Sesión y pautas del agente | Periodo de soporte pendiente de seleccionar. | Las direcciones de versión y el comportamiento de los puntos de control requieren una decisión de versión. |
| Skill de IA versionada | Periodo de soporte pendiente de seleccionar. | Ambas direcciones y el comportamiento ante fallos requieren una decisión de versión. |
| Efectos de las funciones públicas | Sin promesa general de compatibilidad. | Añadir un efecto rompe el contrato de la función pública y requiere una nueva versión mayor del servicio; nunca concede autoridad por sí mismo. |
| Token de coherencia | Periodo de soporte pendiente de seleccionar. | El token forma parte del alcance de servicios de la primera versión; su contrato de compatibilidad requiere una decisión de versión. |
| Mensajes y catálogos localizados | Los identificadores estables de mensajes, catálogos y perfiles nunca se reutilizan. | Las claves públicas y los argumentos tipados se amplían de forma compatible; los mensajes referenciados conservan sus lectores. Las configuraciones regionales, los valores predeterminados y los periodos de soporte de los catálogos siguen abiertos. |
La matriz de soporte de la versión debe especificar, para cada fila, las direcciones de lectura y de escritura, los periodos admitidos, la negociación y el comportamiento ante fallos. No se presupone ninguna garantía de vuelta a una versión anterior ni de portabilidad de puntos de control arbitrarios.
El contrato de chat previsto, neutral respecto al proveedor, abarca contenido, mensajes, eventos, herramientas, salida estructurada y registros persistentes de sesiones y ejecuciones. Las capacidades específicas de un modelo nunca se heredan del nombre de un endpoint genérico.
| Vinculación prevista para la primera versión | Límite de cualificación |
|---|---|
| Proveedor simulado determinista | Necesario para pruebas reproducibles. |
| OpenAI Responses directo | Un artefacto de proveedor exacto y una matriz fijada de capacidades y contratos; no se promete ningún modelo de un fabricante. |
| Anthropic Messages | Un artefacto de proveedor exacto y una matriz fijada de capacidades y contratos. |
| Ollama nativo | Cualificado frente a su contrato nativo, no frente a su interfaz compatible con OpenAI. |
| Endpoint acotado compatible con OpenAI | Vinculación tipada con el endpoint y capacidades comprobadas; no afirma ser OpenAI. |
| Entorno de ejecución coubicado gestionado externamente | Solo reclamaciones acotadas de recursos de cliente de Cygnus; el entorno de ejecución externo no se computa como margen de Cygnus. |
| llama.cpp local certificado y gestionado por Cygnus | Miembro de CPU obligatorio; CUDA solo si está cualificado. El modelo, el tokenizador, el entorno de ejecución, el dispositivo, la configuración y la envolvente de recursos exactos requieren un certificado firmado. |
Los endpoints remotos o los locales operados de forma independiente no heredan las garantías de RAM/VRAM de los locales gestionados. El cálculo nativo de modelos, los agentes nativos amplios de los proveedores, el respaldo automático y el uso ilimitado de IA quedan fuera de este perfil. Los nombres de proveedores y productos solo identifican interfaces; no implican ninguna asociación ni respaldo.
Ninguno de los criterios siguientes se presenta como superado. Las cifras se aplican a las condiciones declaradas de carga de trabajo, hardware y coherencia; los criterios obligatorios y los recomendados se mantienen diferenciados: 22 criterios son obligatorios y 2 recomendados.
| Criterio · evidencia exigida | Umbral propuesto | Requisito · estado |
|---|---|---|
| 01 Socios de diseño en producción con una carga de trabajo del tipo de referencia | Al menos 3 | ObligatorioAún no superado |
| 02 Sistema de registro en producción con historial conservado | Al menos 1, con al menos 6 meses de historial | ObligatorioAún no superado |
| 03 Ingesta sostenida de posiciones en la clase de hardware de referencia propuesta de 32 vCPU, con coherencia transaccional de índices | Al menos 100 000 informes/s | ObligatorioAún no superado |
| 04 Absorción de ráfagas sin descartar datos ni crecimiento ilimitado de colas | 100 000 informes/s durante 60 segundos | ObligatorioAún no superado |
| 05 Buques dentro de un polígono sobre 250 000 posiciones en vivo | p99 de 150 ms como máximo | ObligatorioAún no superado |
| 06 Lectura de la trayectoria de un buque durante 90 días | p99 de 250 ms como máximo | ObligatorioAún no superado |
| 07 Recuperación híbrida dispersa y densa top-20 sobre 5 millones de documentos | p99 de 300 ms como máximo | ObligatorioAún no superado |
| 08 Lectura del entorno de un gemelo, profundidad 3 y 500 nodos como máximo | p99 de 50 ms como máximo | RecomendadoAún no superado |
| 09 Corrección fuera de memoria sin crecimiento ilimitado de la memoria | Conjunto de datos de al menos 24 veces la RAM | ObligatorioAún no superado |
| 10 Sobrecoste de la autorización por elemento frente a una política de grano grueso | 2 veces como máximo | ObligatorioAún no superado |
| 11 Punto de recuperación de commits confirmados en un servidor | Cero commits confirmados perdidos | ObligatorioAún no superado |
| 12 Reinicio con un conjunto de datos de 3 TiB | Las escrituras de referencia se reanudan en 20 segundos como máximo | ObligatorioAún no superado |
| 13 Pruebas programadas de restauración verificada en la ventana de la versión | 100 % superadas | ObligatorioAún no superado |
| 14 Recuperación ante fallos en cada paso del commit | 100 % de las pruebas superadas | ObligatorioAún no superado |
| 15 Evaluaciones de agentes en proyecto vacío sin reparación humana | Al menos el 70 % con éxito dentro de los presupuestos declarados | ObligatorioAún no superado |
| 16 De proyecto vacío a una función de lectura/escritura de gemelo desplegada y autorizada, con cliente TypeScript generado y formulario | 30 minutos como máximo, dirigido por agentes | RecomendadoAún no superado |
| 17 Conjuntos de pruebas de conformidad obligatorios para cada perfil incluido | 100 % superadas | ObligatorioAún no superado |
| 18 Especificaciones congeladas y conjuntos mínimos de pruebas de conformidad | Sustrato del núcleo, descriptores de identidad estables y núcleo de amenazas y seguridad; descriptores de modalidad, lenguaje, proyecto, representación intermedia, planes, esquema, almacenamiento, transacciones, flujos, bloqueo de paquetes, localización y herramientas básicas; servicios, MCP, funciones, UI, TypeScript generado, paquetes de despliegue, flujos de cambios y seguridad completa; búsqueda y tiempo de evento; MCP guiado, proyección de funciones congelada, localización del Explorer, LSP y depuración headless; operación en un solo servidor, interfaz de proveedores nativos y chat acotado. El modelo de amenazas se revisa en cada criterio incluido. | ObligatorioAún no superado |
| 19 Los ejemplos de la documentación se ejecutan como pruebas | 100% | ObligatorioAún no superado |
| 20 Líneas base de regresión de rendimiento con responsables | Cada benchmark de las rutas críticas | ObligatorioAún no superado |
| 21 Matriz completa de soporte y compatibilidad | Formatos exactos, perfiles de documentos, multimedia, ráster y proveedores, configuraciones regionales y catálogos seleccionados; las 19 dimensiones especifican ambas direcciones, periodos, negociación y comportamiento ante fallos; ninguna celda abierta | ObligatorioAún no superado |
| 22 Identidad de producción y activación criptográfica | Proveedor externo de claves cualificado y ceremonia auditada del primer administrador; sin recurso a proveedores de desarrollo o de archivos | ObligatorioAún no superado |
| 22 Divulgación de seguridad y operaciones de versión | Contacto supervisado, clave pública de cifrado, security.txt, canal de avisos de seguridad, calendario de soporte y roles de publicación y reversión ya ensayados | ObligatorioAún no superado |
| 24 Aceptación completa del chat acotado | Aceptación del núcleo, de los cinco adaptadores de proveedores, MCP, conocimiento, local gestionado externamente, local de CPU gestionado y certificado, biblioteca y recursos mínimos | ObligatorioAún no superado |
| 25 Catálogo de bibliotecas de la primera versión | Cada miembro obligatorio cuenta con una versión madura aprobada; los miembros recomendados superan las pruebas o declaran un sucesor y la desviación | ObligatorioAún no superado |
El criterio de versión de 100 000 informes/s en la clase de hardware propuesta de 32 vCPU es independiente de un objetivo de ingeniería más exigente en una clase de hardware más pequeña y sin especificar. Los criterios de seguridad, identidad, proveedores, documentación y matriz de soporte son tan necesarios como el rendimiento.
Las versiones exactas de documentos, multimedia, ráster, vectoriales, intercambio masivo y proveedores, las configuraciones regionales de producción, los periodos de los catálogos y varias direcciones de compatibilidad de agentes, sesiones, skills y tokens siguen abiertas. Deben seleccionarse y cualificarse antes de la 1.0.
Los precios, las licencias, el empaquetado comercial, la financiación de proveedores, los calendarios y las fechas de entrega tampoco están seleccionados. Un objetivo propuesto es una prueba por realizar, no un compromiso con el cliente.
Relaciones, historial, ubicación y búsqueda que tienen que funcionar juntos: lo contrastaremos con el límite previsto de la primera versión y le diremos con franqueza dónde encaja.
O escríbanos a contact@natusai.com
NatusAI