Estado de capacidades
Las afirmaciones públicas utilizan cuatro estados para no confundir comportamiento entregado, aceptación de producción, dependencias del entorno y trabajo planificado bajo una única etiqueta comercial.
40 capacidades
analytics-governed
Reports puede fijar DatasetVersions exactos, crear ReportVersions inmutables y conservar el contexto de permisos, RLS, filtros y ejecución.
La conservación y exportación de resultados son acotadas, y el acceso sigue sujeto a los permisos de los recursos subyacentes.
analytics-postgresql-boundary
El compilador actual de Analytics gobernada y consciente de Dataset está dirigido a PostgreSQL.
Otros orígenes requieren una ruta aceptada de materialización o adaptación de dialecto.
assurance-read-model
Advanexus Assurance crea una historia operativa optimizada para lectura y consciente de permisos a partir de fuentes canónicas de evidencia admitidas.
Los módulos de origen conservan la propiedad canónica y la cobertura de la proyección varía según el evento y el módulo.
assurance-user360-not-score
User 360 presenta una huella de evidencia explorable dentro del ámbito permitido al observador.
No es una puntuación de productividad, rendimiento ni evaluación automatizada de recursos humanos.
assurance-visible-gaps
Assurance distingue evidencia conocida, verificada, no verificada, heredada y no disponible, en lugar de inventar el historial que falta.
Un evento visible o un renderizador genérico no demuestra cobertura semántica completa.
evidence-package-checksum
Los Evidence Packages autorizados pueden incluir salidas acotadas en HTML, PDF, CSV, JSON, NDJSON y ZIP con manifiesto y metadatos de suma de comprobación.
La generación, descarga, caducidad y tamaño conservado siguen acotados y sujetos a permisos.
evidence-package-not-signed
Los Evidence Packages son exportaciones técnicas verificables mediante suma de comprobación; no son registros firmados digitalmente ni legalmente concluyentes de forma automática.
La firma KMS, WORM, el bloqueo de objetos, la retención legal y la certificación regulatoria requieren controles separados.
source-aware-integrity
El estado de integridad refleja la solidez de verificación disponible en cada fuente canónica admitida.
Un Integrity Run correcto aún puede contener registros no verificados, pendientes o heredados.
pricing-operational-scope
Los precios públicos son estimaciones de planificación no vinculantes; el alcance final de Advanexus depende de la responsabilidad operativa aceptada, los sistemas, los controles, las cargas de trabajo y las obligaciones de evidencia.
La propuesta formalizada y el Formulario de pedido siguen siendo la autoridad para el precio, la infraestructura, el soporte, los costes de terceros, la aceptación y las exclusiones.
connector-capabilities-vary
Las capacidades se determinan para cada Source, controlador y despliegue.
El descubrimiento, la vista previa, las consultas, la transferencia, escritura, eliminación, calidad y analítica no son idénticos en todos los conectores.
connector-families
Diecisiete contratos de conectores en ocho familias cubren sistemas relacionales, almacenes, clave-valor, documentales, de columnas anchas, búsqueda, grafos y SaaS empresarial.
MariaDB utiliza la familia compatible con MySQL; la compatibilidad indicada nunca implica paridad funcional.
source-capability-contract
Sources proporciona identidad de conexión dentro del Project y expone únicamente operaciones compatibles con sus capacidades.
La disponibilidad depende de las credenciales, la red, las bibliotecas del proveedor y la política de despliegue.
data-quality-assertions
Data Quality convierte expectativas explícitas orientadas al origen en aserciones SQL, QualityRuns y hallazgos de error.
El SQL personalizado requiere roles de lectura de mínimo privilegio y una revisión cuidadosa de los campos devueltos.
data-quality-boundaries
Las reglas de Data Quality son actualmente contratos de Source mutables, no reglas inmutables fijadas a DatasetVersion.
La ejecución de suites, reparación automática y un flujo completo de remediación de hallazgos no son capacidades actuales.
dataset-version-contract
Dataset aporta identidad estable, DatasetVersions inmutables, linaje y metadatos semánticos a una definición de datos.
El análisis de impacto posterior se limita a contratos y relaciones registrados.
dataset-version-not-row-snapshot
Un DatasetVersion virtual conserva el contrato de consulta y esquema, pero no necesariamente una copia congelada de las filas activas del origen.
Las filas históricas exactas requieren un artefacto de resultado conservado o un contrato explícito de snapshot materializado.
intelligence-actions-controlled
Los modelos pueden proponer; los servicios deterministas validan; las políticas y las personas autorizan las acciones registradas que cambian estado.
La confirmación, aprobación y evidencia dependen del contrato exacto de la acción registrada.
intelligence-bounded
Advanexus Intelligence es una capa de orquestación con estado y consciente de permisos sobre skills y herramientas registradas de la plataforma.
No es un agente autónomo sin restricciones ni un sistema paralelo de autorización.
intelligence-no-screen-scraping
Intelligence utiliza contexto registrado de página, objeto y lista permitida, en lugar de extraer una pantalla o cuadrícula de resultados arbitraria.
No dispone de búsqueda web general, automatización de navegador ni RAG automático sobre documentación.
no-compliance-certification
Este sitio no afirma certificaciones regulatorias o insignias de cumplimiento legal sin evidencia formalmente aprobada.
Los controles del producto pueden respaldar un proceso gobernado, pero no certifican por sí solos a una organización.
pipeline-executors
Los ejecutores Pipeline implementados conservan resultados de consultas, transferencias, eliminaciones, Data Quality y ejecuciones Master.
Las definiciones de jobs son mutables y el catálogo público debe distinguir ejecutores activos de tipos históricos no admitidos.
pipeline-schedule-boundary
Pipeline Schedule conserva la intención de intervalo o cron; no despacha jobs automáticamente.
No existe una garantía universal de JobVersion, cancelación, reintento, reversión o ejecución exactamente una vez.
aws-managed-target
Los límites de ejecución de Advanexus pueden trasladarse a servicios gestionados de AWS para bases, caché, objetos, secretos, observabilidad y cargas de trabajo.
El repositorio no proporciona una pila ECS o CDK de producción aceptada universalmente.
bounded-by-default
Las rutas interactivas de vista previa, búsqueda, grafos, artefactos, exportación, notebook, transformación y paquetes aplican límites explícitos.
Los resultados truncados o parciales siguen identificados como tales y no se presentan como una entrega completa.
production-acceptance-required
La aprobación de producción está vinculada a una revisión exacta, imagen inmutable, infraestructura de destino y evidencia registrada de aceptación.
La documentación, una insignia de preparación o las pruebas del repositorio por sí solas no certifican un despliegue.
tenant-project-scope
Tenant es el límite de la organización y del aislamiento de datos; Project es el ámbito de pertenencia y ejecución dentro de un tenant.
Cada entorno de destino debe superar las pruebas de autorización, migración y rutas negativas.
capability-status-contract
Las capacidades públicas se clasifican como disponibles, orientadas a producción, dependientes del entorno o planificadas.
El estado describe el alcance del producto; no sustituye la aceptación del entorno del cliente.
existing-stack
advanexus está diseñado para trabajar sobre los sistemas de datos existentes, sin exigir su sustitución completa.
La integración sigue requiriendo conectores compatibles y un diseño de despliegue aceptado.
platform-control-layer
advanexus conecta operaciones de datos gobernadas, analítica, trabajo controlado en Python y evidencia disponible mediante un modelo operativo compartido.
La profundidad de las capacidades y la aceptación para producción varían según el módulo y el despliegue.
anpy-boundaries
ANPy es análisis gobernado con Python; no afirma ofrecer MLOps completo, planificación GPU, servicio de modelos o ejecución autónoma.
El montaje de Drive, el acceso directo de tabla a DataFrame y la colaboración completa en notebooks no son capacidades implícitas.
anpy-governed-runtime
ANPy conecta un notebook de Project, un entorno versionado, el ciclo de vida del kernel y una salida acotada de ejecución de celdas.
La producción requiere políticas aceptadas para el gestor del entorno de ejecución, la imagen, el catálogo de paquetes y el aislamiento.
managed-table-versioning
Las transformaciones correctas publican versiones físicas inmutables de tablas tras un alias SQL estable orientado al usuario.
El alias solo se promociona tras la validación; una restauración puede cambiar el esquema esperado por consumidores posteriores.
sandbox-bounded-transform
La inspección previa y publicación acotadas admiten CSV, texto UTF-8 delimitado, registros de objetos JSON y la primera hoja XLSX.
Los límites de formato, tamaño, codificación, delimitador, hoja y parser son explícitos; el contenido no admitido se rechaza de forma segura.
sandbox-file-versions
Sandbox Drive conserva los archivos compartidos del proyecto como versiones inmutables con identidad SHA-256 y contabilización de cuota.
El cifrado, ciclo de vida y recuperación del almacenamiento de producción dependen del despliegue aceptado.
general-deny-boundary
Existen contratos de permisos por módulo; un modelo universal y persistente DENY-wins para toda la plataforma aún no está completo.
El texto público de seguridad no debe insinuar un contrato global de permisos negativos más sólido.
security-boundaries
El contexto de identidad, tenant, Project y permisos propiedad del servidor se revalida en los límites protegidos de aplicación y acceso a datos.
La aceptación de identidad, sesión, roles y rutas negativas del entorno de destino sigue siendo obligatoria.
sql-read-only
SQL Console es una superficie controlada de exploración de solo lectura con validación de Source y ámbito propiedad del servidor.
La capacidad del Source y el dialecto SQL aún determinan qué puede ejecutarse de forma segura.
public-site-accessibility
El sitio público está diseñado para acceso por teclado, estructura semántica, movimiento reducido y lectura adaptable.
La conformidad final requiere pruebas automáticas y manuales sobre la compilación pública exacta.
public-site-data-minimization
El sitio público estático está diseñado para minimizar la recopilación y no requiere un servicio de formulario de contacto integrado en el servidor.
El correo directo sigue los sistemas del remitente y destinatario; la revisión formal del responsable legal sigue siendo requisito de publicación.
public-site-no-nonessential-cookies
El sitio público estático inicial no requiere cookies analíticas, publicitarias u otras no esenciales.
Cualquier tecnología opcional futura requiere revisión de política, consentimiento y documentación antes de publicarse.
Sin resultados
El ledger combina redacción pública revisada con estado, límite, referencias de evidencia, responsable y fecha de última revisión. Los filtros de búsqueda y módulo ayudan a localizar una capacidad; nunca convierten un elemento condicionado o planificado en disponible.
Lo que el contrato actual del producto admite realmente.
La condición de permiso, conector, despliegue o evidencia que debe permanecer visible junto a la afirmación.
Documentación o referencias de pruebas del repositorio utilizadas para revisar; no sustituyen la aceptación del entorno de destino.
Quién debe volver a revisar la afirmación cuando cambien el producto o la redacción pública.
La capacidad existe en el contrato actual del producto, respaldada por implementación o evidencia de pruebas. Todavía pueden aplicar límites de conector, permisos y operación acotada.
La capacidad existe, pero el despliegue exacto de producción exige aceptación de infraestructura, autorización, almacenamiento, recuperación, navegador o servicio en vivo.
La disponibilidad depende del controlador, el entorno de ejecución del proveedor, la red, los secretos, el proceso de trabajo, el almacenamiento, el proveedor del modelo o la política de despliegue.
La capacidad es una mejora documentada o una fase futura. No se presenta como algo en lo que un usuario actual pueda confiar.
Los registros de afirmaciones vinculan redacción pública, referencias de evidencia y fecha de revisión. Un cambio de producto exige revisar la afirmación y su traducción antes de publicar la build pública.
La aprobación de producción pertenece a una revisión Source exacta, imágenes inmutables, infraestructura objetivo y aceptación registrada de migración, autorización, recuperación, almacenamiento, conectores, navegador y operación. Las pruebas del repositorio, una etiqueta de preparación o este ledger público no certifican por sí solos el entorno de un cliente.
Siguiente paso
Incluya los sistemas, responsables, reglas, obligaciones de entrega y requisitos de evidencia relevantes.
Analizar un flujo crítico