Knowledge Layer Architecture
01 / 20
Digital Marketing
Arquitectura inicial

Knowledge Layer

Propuesta para convertir información aprobada en archivos Markdown públicos, estables y legibles por crawlers de LLMs.

Una fuente oficial, gobernada y legible por máquinas para que los LLMs respondan sobre Copa con datos aprobados.

Directus como input S3 como storage CloudFront/WAF como puerta pública SR-0125405 como habilitador IT/Security
Input
Engine
S3
Validación
Markdown
Bots
Owners
Manifest
Logs

Junio 2026 · Seed inicial basado en el playbook LLM Content Repository y notas internas del sprint Knowledge Layer.

Arquitectura inicialKnowledge Layer para crawlers de LLMs. Fuentes: Playbook LLM; kickoff Knowledge Layer.
02 / 20
Decisiones de arquitectura

Este deck debe cerrar quién aprueba, cómo se compila y qué se publica en S3.

La presentación high-level explica el valor del Knowledge Layer. Esta versión técnica define los controles y responsabilidades necesarios para construir un piloto aprobable.

Gobierno editorial

Directus concentra drafts, versiones, fuentes y estados. Los owners validan los hechos y Digital Marketing controla cuándo un contenido queda listo para release.

Procesamiento

El engine externo lee un snapshot aprobado, aplica reglas determinísticas y construye Markdown, índices, manifest y evidencia de QA.

Publicación controlada

S3 recibe primero un release de staging. Solo después del QA y approval final de Digital Marketing se promueve el mismo manifest a producción.

La decisión recomendada es desacoplar aprobación y ejecución: las personas aprueban en Directus; el engine ejecuta reglas; IT/Seguridad aprueba la infraestructura; Digital Marketing autoriza cada publicación.

Propósito técnicoAcordar el modelo operativo antes de escoger la implementación del engine. Fuentes: Directus approval workflows; Directus Flows; Playbook LLM.
03 / 20
Tesis

No estamos creando solo una carpeta en S3. Estamos creando una cadena de confianza.

El bucket es el lugar donde viven los archivos. El valor real está en que cada archivo tenga origen, aprobación, vigencia, estructura y publicación controlada.

01

Directus captura la verdad editable

Permite que Content, Producto y áreas expertas mantengan datos estructurados sin tocar archivos ni código.

02

El engine convierte verdad en artefactos

Valida, transforma, genera Markdown, arma índices, revisa links y publica con trazabilidad.

03

S3/CloudFront expone una capa legible

Sirve archivos estáticos bajo una ruta pública controlada, con HTTPS, caching, logs y reglas de acceso para bots.

La función del engine no es decidir qué es cierto. La función del engine es asegurar que solo lo aprobado llegue al formato correcto, en el lugar correcto, con señales correctas para crawlers.

Decisión claveSeparar CMS editorial, procesamiento y publicación pública. Fuentes: Playbook LLM; Directus Content Versioning; AWS S3 hosting.
04 / 20
Especificación de transformación

Un registro de Directus se convierte en Markdown mediante reglas explícitas.

Cada content type necesita un schema de entrada, una plantilla de salida y una regla de ubicación. El engine no copia texto libre: compila un artefacto verificable.

Contenido editorial

title, summary, facts, body blocks, FAQs, source references y relaciones con destinos, aeropuertos o políticas.

Gobernanza

canonical_id, locale, owner, risk class, effective/expiry date, status y evidencia de approval.

Reglas del engine

Valida schema, normaliza bloques, resuelve links, aplica template, sanitiza contenido y calcula path y hash.

Artefacto generado

Frontmatter YAML + Markdown, alternates, timestamps, source IDs, release_id y entrada correspondiente en el manifest.

Ejemplo en Directus

canonical_id: destination_bog · locale: es-pa · status: ready_for_release · fuentes y approvals relacionados.

Resultado en S3

/ai/destinos/es-pa/sudamerica/bogota.md + registro en manifest.json con hash, Directus ID y S3 Version ID.

Modelo de datosDirectus describe la verdad; el template define cómo esa verdad se representa. Fuentes: Playbook LLM; Directus Content Versioning; S3 Versioning; Directus wiki.
05 / 20
Arquitectura recomendada

Directus gobierna el contenido. Digital Marketing autoriza el release. El engine publica artefactos.

Directus → Engine → S3 staging → Gate Digital → S3 prod + CDN

Control editorial

Directus CMS
Campos estructurados, drafts, versiones y fuentes
Owners de contenido
Validan hechos, vigencia y claims de su dominio
Digital Marketing
Administra workflow y autoriza ready_for_release

Capa de procesamiento

Release job externo
Consulta el snapshot aprobado por API
QA automático
Schema, links, metadata, freshness y DLP contextual
Release manifest
Markdown, índices, checksums, diff y rollback

Publicación inmutable

S3 staging + prod
Separación de permisos y versioning habilitado
CloudFront + WAF
Dominio Copa, HTTPS, cache, WAF y access logs
URLs públicas estables
/ai/, /llms.txt, sitemap y manifest
Arquitectura objetivoS3 nunca recibe borradores ni decide qué contenido es publicable. Fuentes: Directus wiki; Directus Flows; S3 Versioning; CloudFront OAC.
06 / 20
Rol de cada producto

La arquitectura separa la verdad editorial, la decisión de release y la ejecución técnica.

Directus

Source of truth editorial y estructurado. Guarda drafts, versiones, permisos, estados, autores y approvals.

Digital Marketing

Owner operativo del Knowledge Layer. Configura el workflow, coordina approvals, revisa staging y autoriza la promoción a producción.

Engine de procesamiento

Compilador y release runner. No aprueba contenido: lee el snapshot autorizado, valida reglas y produce artefactos reproducibles.

S3

Repositorio de releases generados. Staging y producción tienen versioning, permisos separados y escritura exclusiva del engine.

CloudFront + WAF

Superficie pública bajo dominio Copa. Entrega URLs estables, caching, protección, bot controls y access logs.

IT / Seguridad

Aprueba IAM, infraestructura, exposición, logging, retención y respuesta a incidentes. No sustituye la aprobación editorial.

El principio operativo: Directus guarda la verdad aprobable; Digital Marketing decide el release; el engine ejecuta; S3 conserva el resultado; CloudFront lo expone.

Separación de responsabilidadesEl engine automatiza controles, pero ninguna decisión editorial queda delegada al código. Fuentes: Directus wiki; Directus approval workflows; S3 Versioning; CloudFront OAC.
07 / 20
Arquitectura de archivos

El Knowledge Layer debe ser navegable por humanos, crawlers y scripts.

/
|-- llms.txt                    ← DEBE EXISTIR
|-- sitemap-ai.xml
`-- ai/
    |-- llms-full.txt
    |-- manifest.json
    |-- audiencias.md
    |-- glosario.md
    |-- core/
    |   |-- destinos.md
    |   |-- red-de-rutas.md
    |   `-- ...
    |-- corporativo/
    |   |-- press-releases/
    |   |   |-- 2026/
    |   |   `-- ...
    |   `-- media-kit.md
    |-- operaciones/
    |   |-- politicas-equipaje.md
    |   `-- ...
    |-- comercial/
    |   |-- partners/
    |   `-- ...
    |-- destinos/
    |   |-- es-pa/sudamerica/bogota.md
    |   |-- en-us/north-america/miami.md
    |   |-- pt-br/sudamerica/sao-paulo.md
    |   `-- ...
    `-- _meta/
        |-- changelog.md
        `-- ...

Raíz pública

/llms.txt DEBE EXISTIR en la raíz del dominio. Si IT no permite raíz, se necesita redirección o alias aprobado hacia /ai/llms.txt.

Un destino, un archivo

La unidad recomendada es aeropuerto/destino, no ruta. PTY se documenta una vez en core/modelo-hub.md.

Metadata obligatoria

Cada MD necesita fecha, fuente, owner, vigencia, locale, estado y nivel de revisión.

Press releases

Entran en corporativo/press-releases/ como fuente pública fechada. No reemplazan archivos canónicos de core/ o destinos/.

Convención recomendadaMarkdown público + índices técnicos + metadatos de vigencia. Fuentes: Playbook LLM; llms.txt proposal; Google Sitemaps; Google localized versions.
08 / 20
Qué información entra

Antes de asignar owners, hay que definir el inventario de conocimiento.

core/

Verdad compartida: red de rutas, destinos, flota, hub PTY, alianza, historia y presencia geográfica.

Base para todas las audiencias

operaciones/

Políticas de equipaje, tarifas, check-in, embarque, ConnectMiles, conexiones y reglas de servicio.

Requiere validación operativa

comercial/

Codeshares, interlínea, alianzas, partners y beneficios comerciales documentados como intersección con Copa.

Comercial + Alianzas

destinos/

Un MD por aeropuerto: operación específica, terminal, frecuencia, acceso terrestre, requisitos y particularidades.

Primer piloto: top rutas T1

audiencias/

Lentes de interpretación para pasajeros, call center, partners, inversores, empleados y candidatos.

No duplica hechos

dynamic/

Rangos con fecha explícita, lógica de precios y apuntadores a fuentes vivas cuando existan APIs aprobadas.

No publicar precios exactos estáticos

Regla editorial: si el dato no cambia por ser Copa, o no tiene fuente aprobada, probablemente no pertenece al Knowledge Layer.

Inventario inicialDefinir contenido primero; nombres de owners después. Fuentes: Playbook LLM; Directus wiki.
09 / 20
Opciones del engine

Hay tres formas viables de convertir contenido aprobado en releases Markdown.

A. Event-driven

Un cambio de estado en Directus dispara un Flow que invoca Lambda, un container o un endpoint interno.

  • Ventaja: feedback rápido y poca operación manual.
  • Riesgo: acopla cada transición editorial al pipeline técnico.
  • Uso: notificar o preparar staging; no publicar directamente.

B. Release job por lote

Digital Marketing inicia un release. El runner consulta todos los registros ready_for_release y compila un paquete determinístico.

  • Ventaja: control, reproducibilidad y rollback claro.
  • Riesgo: no es publicación inmediata.
  • Uso: opción recomendada para el MVP.

C. GitOps intermedio

El engine genera Markdown en una rama; un pull request aprobado despliega el release a S3.

  • Ventaja: auditoría técnica y diff muy fuertes.
  • Riesgo: duplica approvals y exige operación Git.
  • Uso: fase posterior si IT lo requiere.

Recomendación: release job por lote, iniciado manualmente por Digital Marketing o solicitado por un Flow. Directus orquesta el estado; el procesamiento y las credenciales AWS viven fuera del CMS.

Decisión de implementaciónEl trigger puede cambiar; la estructura del release debe permanecer estable. Fuentes: Directus Flow triggers; Directus Flow operations; AWS Lambda; Playbook LLM.
10 / 20
Proceso recomendado

El engine convierte un snapshot aprobado de Directus en un release reproducible.

1

Cierra contenido

Digital Marketing mueve los registros aprobados a ready_for_release.

2

Inicia release

Botón manual, Flow o pipeline crea un release_id único.

3

Lee snapshot

Cuenta de servicio read-only consulta registros, relaciones y versiones aprobadas.

4

Normaliza y valida

Schema, fuentes, slugs, locales, vigencia, links y políticas.

5

Compila

Genera frontmatter, Markdown, llms.txt, sitemap y manifest.

6

Publica staging

Escribe el paquete, ejecuta crawl QA y genera diff contra producción.

7

Promueve

Digital Marketing aprueba el preview; el engine promueve ese mismo manifest.

Datos que viven en Directus

  • canonical_id, tipo, slug, locale y contenido estructurado.
  • Fuente, vigencia, owner, risk class y approvals.
  • Estado editorial y relación entre traducciones.

Datos que genera el engine

  • release_id, hash, S3 key, object version y timestamps.
  • Markdown, manifest, índices, sitemap, QA report y diff.
  • Resultado de deploy y referencia de rollback.
Proceso del engineInput aprobado + reglas versionadas = paquete de release verificable. Fuentes: Directus Flow triggers; Directus Content Versioning; S3 Versioning; Playbook LLM.
11 / 20
Engine hardening

El engine demuestra que ejecutó controles; no sustituye el juicio editorial.

Seguridad puede aprobar controles verificables. La exactitud factual sigue siendo responsabilidad del owner y del workflow humano.

Integridad de entrada

Schema obligatorio, normalización a texto, sanitización de HTML/CSS/scripts, rechazo de caracteres invisibles y allowlist de links y componentes.

Mitigación de contenido malicioso

Reglas para instrucciones ocultas, ofuscación, base64 y patrones de prompt injection. Genera alertas y bloqueo, sin prometer detección perfecta.

DLP y secrets contextual

Busca categorías sensibles, credenciales y datos de pasajeros. Permite nombres públicos autorizados en press releases mediante reglas y excepciones auditadas.

Identidad y mínimo privilegio

  • Service account read-only para consultar Directus.
  • Rol de deploy con escritura limitada a staging/prod.
  • Secrets fuera del CMS y rotación según política IT.

Trazabilidad y reversibilidad

  • Hash por archivo, manifest firmado y ejecución idempotente.
  • Rollback por release y S3 Version ID, nunca edición humana en el bucket.
  • Resultado del release escrito nuevamente en Directus.

La defensa es por capas: permisos, normalización, reglas estáticas, DLP, revisión humana, staging, firma y rollback. Ningún scanner garantiza por sí solo integridad semántica.

Controles del engineMitigación por capas, evidencia auditable y mínimo privilegio. Fuentes: OWASP LLM01 Prompt Injection; S3 Versioning; Directus Permissions; políticas corporativas de Disclosure/Confidencialidad.
12 / 20
Aprobación editorial

Digital Marketing administra el workflow y conserva el control final de publicación.

draft

Autor prepara

  • Completa campos, fuente, locale y vigencia.
  • Solo puede enviar a revisión.
domain_review

Owner valida

  • Confirma exactitud y ownership del dato.
  • Devuelve o aprueba el contenido.
compliance_review

Revisión condicional

  • Legal/Compliance entra según risk_class.
  • No todos los contenidos requieren este gate.
ready_for_release

Digital aprueba

  • Verifica metadata, traducciones y approvals.
  • Solo este estado puede entrar al engine.
staging → published

Digital libera

  • Revisa preview, diff y QA report.
  • Aprueba promoción o devuelve a corrección.

Los permisos de Directus deben restringir quién puede cambiar cada estado. El engine valida el estado, pero no puede otorgarse a sí mismo un approval ni promover contenido sin autorización de Digital Marketing.

Control editorialDigital Marketing gobierna estados, staging y autorización de producción. Fuentes: Directus approval workflows; Directus Permissions; Directus Flow triggers; políticas corporativas de Disclosure/Confidencialidad.
13 / 20
S3 + CloudFront

S3 conserva releases versionados; CloudFront expone rutas públicas estables.

Modelo de almacenamiento

  • Preferible: buckets separados para staging y producción; IT puede exigir cuentas o prefixes separados.
  • S3 Versioning habilitado en ambos ambientes.
  • Paquete inmutable en releases/{release_id}/ con Markdown, índices, QA y manifest.
  • Producción mantiene keys públicas estables como /ai/destinos/.../bogota.md.
  • El manifest relaciona cada URL con hash, S3 Version ID y fuente Directus.
  • Solo el rol del engine escribe; humanos nunca editan archivos directamente.

Modelo de serving

  • Bucket privado como origin y CloudFront con Origin Access Control.
  • Dominio Copa, TLS, WAF, access logs y alarmas.
  • Content-Type y Cache-Control definidos por tipo de artefacto.
  • ETag y Last-Modified tratados como headers de sistema.
  • Invalidación selectiva de URLs cambiadas después de cada promoción.
  • stale-while-revalidate y stale-if-error como buffer de disponibilidad.

Rollback recomendado: seleccionar un manifest anterior y promoverlo como un nuevo evento de release. El engine restaura las versiones correspondientes, actualiza las keys estables y registra el resultado en Directus.

Modelo de releaseArtefactos inmutables para auditoría; URLs estables para crawlers y usuarios. Fuentes: S3 Versioning; CloudFront file versioning; CloudFront OAC; CloudFront cache expiration.
14 / 20
Discovery por bots

llms.txt ayuda, pero no reemplaza robots.txt, sitemap ni WAF.

SeñalFunción
llms.txtÍndice curado para LLMs. En esta arquitectura es obligatorio, aunque sigue siendo una convención emergente.
sitemap-ai.xmlLista URLs importantes, fechas de actualización y locales para crawlers.
robots.txtDeclara acceso esperado por user-agent y path; no es una barrera de seguridad.
WAF + rate limitsProtege la superficie, limita abuso y aplica reglas para bots aprobados.
LogsConfirma quién entra, qué lee, frecuencia, volumen y errores.

Decisiones que debe cerrar Seguridad/IT

  • Permitir crawlers de búsqueda AI en /ai/: OAI-SearchBot, PerplexityBot, Googlebot/Bingbot y otros aprobados.
  • Separar crawling para búsqueda de crawling para entrenamiento cuando el proveedor lo permita.
  • Definir el tratamiento de agentes iniciados por usuario como ChatGPT-User y Perplexity-User.
  • Aplicar rate limits, monitoreo de costos y respuesta ante scraping agresivo.
  • Actualizar reglas cuando existan rangos IP o mecanismos oficiales de verificación.

User-triggered fetch es una visita iniciada por una persona cuando pide al asistente consultar una página. No es crawling automático; debe medirse y gobernarse como un patrón de acceso distinto.

DiscoveryÍndice, sitemap, robots, WAF, rate limits y logs trabajan juntos. Fuentes: llms.txt proposal; OpenAI Crawlers; Google Sitemaps; AWS WAF rate-based rules; Perplexity Crawlers.
15 / 20
SR-0125405

El ticket a IT/Seguridad es el gate que convierte la idea en infraestructura aprobada.

Infraestructura que debe solicitar

  • Ambientes S3 staging/prod con versioning, cifrado, ownership y retención definidos.
  • CloudFront + OAC bajo rutas aprobadas de copaair.com.
  • Runtime del engine: Lambda, container o CI runner según estándares internos.
  • IAM: lectura limitada de Directus y escritura exclusiva del engine en S3.
  • Secrets management, logs, alertas, WAF, rate limits y procedimiento de rollback.

Decisiones que debe devolver IT/Seguridad

  • Separación por buckets, prefixes, cuentas o ambientes corporativos.
  • Mecanismo autorizado para que Directus/Flow solicite un release.
  • Ubicación del engine y patrón de identidad entre Directus, runner y AWS.
  • Políticas de cache, invalidación, logs, retención y respuesta a incidentes.
  • Clasificación formal de contenido público y controles para bots en /ai/.

Mensaje para la reunión: SR-0125405 no pide solo un bucket. Pide un camino de publicación completo, con identidad, staging, producción, serving público, auditoría y rollback.

TicketInfraestructura, identidad, exposición, operación y respuesta ante incidentes. Fuentes: Minuta Knowledge Layer; políticas corporativas de Disclosure/Confidencialidad; S3 Versioning; CloudFront OAC; AWS WAF rate-based rules.
16 / 20
Plan de trabajo

Próximo paso: piloto pequeño, aprobado y medible.

Semana 1

Cerrar decisiones

  • Release job recomendado y runtime candidato.
  • Arquitectura para EPAM/Digital y scope Directus para Aníbal.
  • Architecture brief para SR-0125405.
Semana 2

Modelar contenido

  • Collections, campos y relaciones iniciales.
  • Estados, roles y permisos de aprobación.
  • Locales ES/EN/PT y risk class para T1.
Semana 3

Construir engine MVP

  • Consulta de snapshot aprobado.
  • Templates MD, validaciones y manifest.
  • Deploy a staging y QA report.
Semana 4

Ejecutar release T1

  • Top destinos/rutas.
  • core/modelo-hub.md.
  • Approval Digital, promoción prod y rollback test.
Semana 5

QA y medición

  • Crawl test y revisión de headers.
  • CloudFront/WAF log review.
  • Prompt baseline por mercado/idioma.

Regla operativa: cada hito importante genera un brief de correo con decisión tomada, evidencia, impacto, riesgo y próximo ask.

RoadmapDecisiones, workflow, engine MVP, primer release y medición. Fuentes: Open items; Directus wiki; Playbook LLM; brief LLYC medición.
17 / 20
Idiomas y locales

El LLM puede traducir, pero la fuente oficial debe existir en los idiomas clave.

No depender solo del LLM

Los modelos traducen al responder, pero si el MD oficial existe solo en un idioma, aumenta el riesgo de matices perdidos, respuestas incompletas y baja visibilidad por mercado.

Modelo recomendado

Publicar canónicos ES, EN y PT para contenido T1. Crear variantes por locale solo cuando cambien reglas, mercado, lenguaje legal o contexto operativo.

Metadata mínima

language, locale, source_language, translation_status, reviewed_by, last_reviewed y URL alterna.

Ruta sugerida

  • /ai/destinos/es-pa/sudamerica/bogota.md
  • /ai/destinos/en-us/south-america/bogota.md
  • /ai/destinos/pt-br/america-do-sul/bogota.md

Criterio editorial y regla de release

Traducción automática puede acelerar drafts, pero el publish requiere revisión humana u owner aprobado para evitar claims incorrectos en travel, políticas, requisitos y operación.

T1 crítico: Digital Marketing define locales obligatorios y el engine bloquea si falta uno. Si una traducción ya publicada vence, queda stale y dispara corrección. No crítico: permite release parcial con alternates explícitos.

LocalizaciónLa matriz de locales obligatorios forma parte de los criterios de cada release. Fuentes: Playbook LLM; Google localized versions; schema scripts internos.
18 / 20
Gates y entregables

Para pedir approval, llevamos documentos específicos por audiencia.

EPAM / Digital

Arquitectura v0.1

  • Diagrama end-to-end.
  • Opción de engine y modelo de release.
  • Public path, staging/prod y límites técnicos.
Aníbal

Directus brief

  • Collections y campos requeridos.
  • Estados, roles y permisos.
  • Service account y mecanismo de trigger.
Alineación

Modelo operativo

  • Qué usamos de cada producto.
  • Digital Marketing como release owner.
  • Dependencias, owners y escalamiento.
Seguridad / IT

Architecture doc

  • Clasificación de datos.
  • Runtime, IAM, WAF, robots y logs.
  • Rollback, retención y monitoreo.
Hitos

Email brief

  • Decisión tomada.
  • Evidencia y links.
  • Riesgo y próximo ask.

No cerramos arquitectura final hasta tener approval EPAM/Digital, approval de Aníbal sobre Directus y validación de Seguridad/IT sobre SR-0125405. Después se formaliza el runbook de Digital Marketing.

GovernanceApproval por producto, security gate y briefs de avance por hito. Fuentes: Minuta Knowledge Layer; Directus Access Control; CloudFront OAC; políticas corporativas revisadas.
19 / 20
Monitoreo y medición

Medimos acceso, cobertura y calidad de respuestas, no solo “si existe el bucket”.

Accesibilidad

  • HTTP 200/3xx/4xx.
  • Content-Type correcto.
  • Sitemap y freshness.
  • Errores WAF/CDN.

Cobertura

  • % entidades con MD aprobado.
  • Locales disponibles.
  • Metadata completa y vigente.
  • Drift Directus vs. manifest prod.

AI visibility

  • Prompts por mercado/idioma.
  • Presencia de Copa en respuesta.
  • Citation/source usage.
  • Accuracy review.

Gobernanza

  • Lead time de aprobación.
  • Releases exitosos/fallidos.
  • Rollbacks y contenido stale.
  • Incidentes y tiempo de recuperación.

Baseline conceptual: release manifest + logs de engine/CloudFront/WAF + crawl QA + prompts controlados. Digital Marketing recibe un dashboard operativo y un brief por hito; al inicio no se promete atribución comercial exacta.

MediciónEl monitoreo cubre pipeline, publicación, contenido y visibilidad AI. Fuentes: brief LLYC visibilidad LLM; OpenAI Crawlers; Perplexity Crawlers; Google Sitemaps.
20 / 20
Fuentes y supuestos

Base usada para esta propuesta

Fuentes internas

  • Playbook interno: sources/notes/copa-llm-md-files-playbook.md.
  • Notas de sesión Knowledge Layer 2026-05-20 y 2026-05-26.
  • Entidad Directus del wiki interno: CMS canónico de destinos.
  • Políticas corporativas revisadas: Disclosure, Insider Trading, Whistleblower y archivo de confidencialidad Q1 2026.
  • 00-admin/DEVELOPMENT_POLICIES.md: logging de actividad y vendor governance.

Fuentes externas

Supuesto principal: S3 será el repositorio de salida, pero la URL pública debe quedar bajo dominio Copa y controlada por CDN/WAF para cumplir seguridad y discovery.

CierreEl Knowledge Layer es contenido público aprobado, no una base interna expuesta. Fuentes: links listados en esta slide; archivos internos citados arriba.