Knowledge Layer · arquitectura técnica01 / 09Información de Copa, organizada y aprobada para su consulta por bots y LLMs.
02 / 09En este proyecto, es una colección de información oficial de Copa, organizada por temas, con fuentes identificadas y un proceso para mantenerla vigente.
Hechos, políticas y respuestas aprobadas, con su fuente, idioma, alcance y vigencia.
El equipo revisa cambios, aprueba nuevas versiones y corrige o retira contenido cuando corresponde.
Publicar esa información en un formato que los bots puedan consultar y utilizar como referencia.
El engine prepara el contenido; el Knowledge Layer es la salida publicada. Las fuentes originales siguen siendo la referencia factual.
No es un chatbot ni un entrenamiento del modelo. No garantiza que un LLM elija o cite nuestra información.
03 / 09Desarrollaremos un engine interno que convierta información existente de varias fuentes en Markdown, con las reglas del playbook y aprobación antes de publicar.
Páginas públicas
APIs autorizadas
Documentos aprobados
Directus puede ser otra entrada.
Crawler y conectores
Reglas del playbook
Validación y Markdown
Genera una versión para revisar.
Revisa cambios y fuentes.
Aprueba la versión o solicita correcciones.
El engine escribe los archivos aprobados.
Conserva versiones para recuperación.
CloudFront/WAF, por validar con IT.
/ai/ y /llms.txt
Bots y LLMs
04 / 09El crawler extrae páginas. Otros conectores reciben datos y documentos. Todos pasan por las mismas reglas de publicación.
Leer el contenido relevante y conservar su fuente.
Organizar hechos por entidad, idioma y dominio.
Revisar vigencia, conflictos, datos sensibles y enlaces. Los casos dudosos requieren revisión.
Generar archivos e índices con una versión identificable para aprobación.
/ai/{idioma}/
core/
prensa/ ...
operaciones/ ...
comercial/ ...
destinos/ ...
audiencias/ ...
dynamic/ ...
/llms.txt
/llms-full.txt
/audiencias.mdSolo fuentes autorizadas para el Knowledge Layer, con audiencia y vigencia. Manuales y ejemplos no se convierten automáticamente en políticas. Datos en vivo fuera del snapshot público.
05 / 09La duda es dónde gestionar el trabajo editorial y la aprobación. La extracción y la generación de Markdown quedan en nuestro engine.
| Necesidad | Papel posible de Directus | Trabajo del engine |
|---|---|---|
| Una página existente | Registrar su responsable y reglas, si se necesita. | Rastrear la página y extraer su contenido. |
| Otra fuente aprobada | Recibir datos o referencias a documentos. | Leerlos mediante el conector correspondiente. |
| Corrección y aprobación | Registrar solicitud, evidencia, revisión y decisión. | Regenerar, publicar lo aprobado y devolver el estado. |
06 / 09El control combina rastreo programado, detección de cambios y solicitudes del equipo con URL o MD y evidencia.
Identificar archivo y dato incorrecto.
Determinar dónde está el error y quién lo corrige.
El engine procesa la fuente corregida.
Mercadeo Digital revisa la nueva versión.
Repetir la extracción y comprobar el resultado.
Corregir con su responsable antes de regenerar.
Ajustar la extracción y repetir la validación.
Detener la publicación afectada y pedir revisión.
Error crítico ya publicado: retirar el MD o recuperar una versión verificada; actualizar índices y caché mientras se corrige la fuente.
07 / 09Supuesto de 20 KB por Markdown. El conteo incluye todos los idiomas. Son escenarios de planificación, todavía sin medición del crawler.
| Archivos MD | Solo Markdown | Publicado + índices | Con historial y staging |
|---|---|---|---|
| 500 | 10 MB | 22 MB | 0.68 GB |
| 2,000 | 40 MB | 88 MB | 2.73 GB |
| 10,000 | 200 MB | 440 MB | 13.64 GB |
Cálculo: MD × 20 KB × 2.2 por versión. Total: 30 versiones completas, incluida la actual, + 1 copia de staging. Unidades decimales.
Referencia para IT si llegamos a 10,000 MD con esos supuestos. No es una cuota ni una medición de Copa.
El factor 2.2 incluye una copia en llms-full.txt y 20% del MD base para índices. Si el tamaño promedio se duplica, el espacio también.Excluye HTML crudo, documentos fuente, imágenes, logs y transferencia. La retención debe evitar versiones adicionales sin límite.
08 / 09El desarrollo del engine será interno. Falta validar su ejecución, el papel de Directus y las condiciones de publicación.
Seleccionar fuentes, reglas y responsables de contenido.
Revisar los cambios y aprobar cada versión.
Validar con Aníbal si Directus alojará fuentes, solicitudes y aprobaciones.
Confirmar permisos e integración.
Validar con Digital dentro de IT / EPAM dónde corre el engine y cómo escribe en S3.
Arquitectura y acceso público: seguimiento SR-0125405.
Piloto propuesto: una página, una segunda fuente autorizada y un reporte de error. Probar generación, aprobación, publicación y retiro o recuperación.
Medición: retraso entre fuente y MD, revisiones vencidas, fallos de extracción, tiempo de aprobación y accesos a archivos. Los accesos no demuestran citación.
09 / 09En equipaje, las citas apuntan a un manual de reservas y a un comunicado para agencias, en lugar de una página de Copa orientada al pasajero.
No sabemos por qué seleccionó esos PDFs. Son públicos y oficiales, pero su audiencia y vigencia requieren revisión. Su antigüedad no demuestra que estén derogados ni que sean confidenciales.
Alcance del comunicado de equipaje de mano. La revisión no certifica la franquicia vigente de un boleto.
Convertir todo a Markdown puede repetir el problema. Necesitamos seleccionar, revisar, corregir y retirar contenido. El Knowledge Layer no garantiza que un LLM deje de citar los PDFs existentes.