# Course Assembly Pattern System — CAPS ## Documento fundacional **Versión:** 0.9 **Estado:** Propuesta fundacional consolidada para validación **Ámbito:** Producción y montaje de cursos en Moodle **Fecha de corte:** 27 de julio de 2026 **Responsable de consolidación:** Andres Guillermo Caviedes Campos2_840_SEGURIDAD_SOCIAL_CUENTA_6 **Instancia de validación:** Por definir durante la alineación institucional --- ## Índice 0. [Resumen ejecutivo y guía de validación](#0-resumen-ejecutivo-y-guía-de-validación) 1. [Manifiesto fundacional](#1-manifiesto-fundacional) 2. [Contexto estratégico](#2-contexto-estratégico) 3. [Definición estratégica de CAPS](#3-definición-estratégica-de-caps) 4. [Marco conceptual de CAPS](#4-marco-conceptual-de-caps) 5. [Principios arquitectónicos de CAPS](#5-principios-arquitectónicos-de-caps) 6. [Arquitectura de pilares de CAPS](#6-arquitectura-de-pilares-de-caps) 7. [Modelo operativo mínimo de CAPS](#7-modelo-operativo-mínimo-de-caps) 8. [Modelo organizacional y de responsabilidades de CAPS](#8-modelo-organizacional-y-de-responsabilidades-de-caps) 9. [Modelo de activos y catálogo de CAPS](#9-modelo-de-activos-y-catálogo-de-caps) 10. [Gobernanza y evolución de CAPS](#10-gobernanza-y-evolución-de-caps) 11. [Modelo de madurez y medición de CAPS](#11-modelo-de-madurez-y-medición-de-caps) 12. [Hoja de ruta de implementación de CAPS](#12-hoja-de-ruta-de-implementación-de-caps) 13. [Visión futura y propuesta de valor institucional](#13-visión-futura-y-propuesta-de-valor-institucional-de-caps) 14. [Anexos de validación](#anexos-de-validación) --- # 0. Resumen ejecutivo y guía de validación ## 0.1. Resumen ejecutivo El área de producción de cursos dispone de conocimiento valioso acumulado en personas, cursos, documentos, fragmentos de código, configuraciones de Moodle y prácticas de montaje. Sin embargo, este conocimiento todavía no conforma un sistema institucional integrado. En consecuencia, problemas similares pueden resolverse varias veces, los componentes pueden copiarse sin conocer sus condiciones de uso y la calidad del resultado puede depender excesivamente de la experiencia individual. **Course Assembly Pattern System — CAPS** propone convertir esa experiencia en una capacidad organizacional. El framework organiza el conocimiento del montaje mediante patrones que explican un problema recurrente, el contexto en el que aparece, el resultado esperado, los criterios que debe cumplir la solución, las adaptaciones admitidas y la forma de validar su aplicación. CAPS diferencia expresamente: - El **patrón**, que conserva el conocimiento de la solución. - La **plantilla**, que facilita la aplicación recurrente de uno o varios patrones. - El **componente**, que proporciona una pieza funcional reutilizable. - La **implementación**, que materializa la solución en Moodle o en una tecnología específica. - El **caso de aplicación**, que aporta evidencia de uso. - La **lección aprendida**, que permite corregir o evolucionar el sistema. El framework no busca uniformar todos los cursos, reemplazar el criterio profesional ni convertir el montaje en una secuencia rígida. Su propósito es reducir decisiones repetitivas, hacer explícitos los criterios institucionales, facilitar la colaboración interdisciplinaria, preservar el conocimiento y ofrecer una base confiable para la automatización y el uso de inteligencia artificial. La propuesta se estructura mediante seis pilares: arquitectura de conocimiento, producción, pedagogía, experiencia y comunicación visual, técnica y componentes, y automatización e inteligencia artificial. La gobernanza y la evolución operan como una capacidad transversal. En la práctica, CAPS propone un ciclo sencillo: > **Necesidad → consulta → ensamblaje → validación → aprendizaje → evolución.** La implementación comenzará con un catálogo mínimo de patrones relacionados con necesidades frecuentes de montaje. Estos patrones se probarán en cursos reales y se evaluarán según su utilidad, claridad, compatibilidad, mantenibilidad y capacidad para reducir trabajo repetitivo o retrabajo. La versión 0.9 no presenta CAPS como un sistema terminado. Presenta la arquitectura conceptual y organizacional necesaria para iniciar su validación. Su aprobación permitirá pasar a un piloto controlado; no supone todavía la aprobación individual de todos los patrones, componentes, plantillas, prompts, automatizaciones o herramientas mencionadas. ## 0.2. Propósito de la validación La validación de esta versión busca confirmar: - Que el problema descrito representa una necesidad real del área. - Que el propósito y el alcance de CAPS son pertinentes. - Que el vocabulario permite coordinar perfiles pedagógicos, visuales, técnicos y operativos. - Que la distinción entre patrón, plantilla, componente e implementación resulta comprensible y útil. - Que los principios arquitectónicos ofrecen criterios suficientes para orientar decisiones. - Que el modelo operativo puede integrarse al trabajo sin introducir una carga desproporcionada. - Que las funciones y derechos de decisión son viables. - Que la hoja de ruta permite comenzar con un alcance controlado. - Que existen condiciones para ejecutar un piloto. La validación no incluye todavía: - Aprobar todos los patrones sugeridos. - Declarar vigentes todos los componentes existentes. - Seleccionar una herramienta tecnológica definitiva. - Formalizar nuevos cargos. - Automatizar el proceso de montaje. - Integrar CAPS automáticamente con Moodle. - Extender CAPS a todos los tipos de curso. ## 0.3. Audiencias de validación La revisión deberá involucrar, de manera proporcional, las siguientes funciones: - Orientación estratégica o coordinación de la producción. - Diseño instruccional y acompañamiento pedagógico. - Producción y montaje en Moodle. - Diseño visual, experiencia y accesibilidad. - Administración funcional o desarrollo técnico de Moodle. - Gestión del conocimiento o documentación, cuando exista esta capacidad. - Usuarios que aplicarán los patrones en proyectos reales. No todas las personas necesitan revisar todos los apartados. Cada perfil deberá concentrarse en las decisiones relacionadas con su competencia, mientras la función de arquitectura consolida la coherencia general. ## 0.4. Evidencia de partida y supuestos por verificar El documento parte de evidencias cualitativas iniciales: - Existe un repositorio con ejemplos de listas, lecturas, banners, botones, tarjetas, carruseles y otros recursos utilizados en Moodle. - El uso correcto de estos elementos depende parcialmente del conocimiento de las personas que los han creado o utilizado. - Existen soluciones semejantes que pueden haberse desarrollado o adaptado de forma independiente. - No todos los activos muestran con claridad su vigencia, propósito, restricciones, responsable o estado de validación. - El conocimiento obtenido durante un curso no siempre se incorpora a una base institucional reutilizable. - La incorporación de inteligencia artificial aumenta la necesidad de contar con criterios y patrones previamente definidos. Estas observaciones constituyen hipótesis de diagnóstico y deberán contrastarse durante la fase de alineación mediante: - Inventario de activos y componentes. - Agrupación de soluciones por necesidad. - Identificación de duplicaciones y obsolescencia. - Revisión de consultas y correcciones recurrentes. - Registro inicial de tiempos de montaje. - Identificación de dependencias respecto de personas específicas. - Revisión de cursos que representen diferentes tipologías. La versión 1.0 deberá diferenciar las observaciones confirmadas, los datos obtenidos y los supuestos que todavía requieran seguimiento. ## 0.5. Decisiones abiertas para la validación | ID | Decisión | Pregunta de validación | Instancia sugerida | |---|---|---|---| | DEC-01 | Alcance inicial | ¿CAPS comenzará exclusivamente con patrones relacionados con el montaje de cursos? | Orientación estratégica | | DEC-02 | Nombre del sistema | ¿Se adopta el nombre Course Assembly Pattern System y la sigla CAPS? | Orientación estratégica y equipo | | DEC-03 | Vocabulario | ¿Las definiciones de patrón, plantilla, componente e implementación son comprensibles y suficientes? | Arquitectura y especialistas | | DEC-04 | Arquitectura | ¿Qué persona o función conservará la integridad conceptual durante el piloto? | Orientación estratégica | | DEC-05 | Curaduría | ¿Quién organizará el catálogo y mantendrá estados, versiones y relaciones? | Orientación estratégica | | DEC-06 | Patrones iniciales | ¿Cuáles necesidades recurrentes conformarán el primer catálogo? | Equipo de producción | | DEC-07 | Cursos piloto | ¿Qué proyectos permitirán probar CAPS en condiciones reales? | Coordinación de producción | | DEC-08 | Herramienta | ¿Qué herramienta disponible soportará inicialmente el catálogo mínimo? | Arquitectura y curaduría | | DEC-09 | Medición | ¿Qué línea base e indicadores pueden registrarse sin aumentar excesivamente la carga? | Coordinación y equipo piloto | | DEC-10 | Paso a versión 1.0 | ¿Qué evidencias y decisiones se exigirán para aprobar el pilotaje? | Orientación estratégica | ## 0.6. Preguntas rectoras para los revisores 1. ¿El problema estratégico refleja la realidad del área? 2. ¿CAPS aporta una capacidad distinta de un repositorio de código o un manual de estilo? 3. ¿Los conceptos pueden aplicarse a ejemplos reales de montaje? 4. ¿Las responsabilidades propuestas son viables con la estructura disponible? 5. ¿El modelo facilita la reutilización sin limitar adaptaciones justificadas? 6. ¿La gobernanza concentra la revisión en los cambios de mayor riesgo? 7. ¿Qué aspecto del framework resultaría difícil de aplicar? 8. ¿Qué debe aclararse antes de iniciar un piloto? 9. ¿Qué no debería formar parte todavía del alcance? 10. ¿Qué evidencia permitiría afirmar que CAPS aporta valor? ## 0.7. Criterio de cierre de la validación fundacional La versión podrá avanzar a 1.0 cuando: - El propósito y el alcance hayan sido confirmados. - El vocabulario principal haya sido comprendido y ajustado. - Las observaciones críticas hayan sido resueltas o tengan un tratamiento acordado. - Se haya designado una responsabilidad provisional de arquitectura y curaduría. - Se hayan seleccionado los patrones y cursos del piloto. - Exista una ficha canónica aplicable por una persona distinta de su autor. - Se hayan definido criterios mínimos de validación y medición. - La instancia responsable autorice explícitamente el pilotaje. --- # 1. Manifiesto fundacional ## Construimos capacidad organizacional, no solo cursos Cada curso representa una oportunidad para convertir la experiencia del equipo en conocimiento organizado, compartido y reutilizable. Nuestro propósito no es únicamente responder a una solicitud de producción, sino fortalecer de manera progresiva la capacidad institucional para diseñar, ensamblar y evolucionar experiencias de aprendizaje. CAPS nace para transformar conocimientos dispersos, soluciones individuales y prácticas informales en un sistema común de patrones para el montaje de cursos. Integra decisiones pedagógicas, visuales, técnicas y de organización de la información dentro de una arquitectura coherente, comprensible y sostenible. CAPS no es solamente un repositorio de código, una biblioteca de componentes ni un manual rígido de producción. Es un framework de conocimiento que permite documentar, validar, reutilizar y mejorar las soluciones construidas por el área. Creemos que la calidad surge cuando las decisiones dejan de depender exclusivamente de la experiencia de algunas personas y pasan a formar parte de un sistema compartido. El conocimiento producido pertenece a la organización, debe permanecer disponible y debe poder evolucionar con nuevos proyectos, tecnologías y aprendizajes. Defendemos la integridad conceptual: muchas personas y disciplinas pueden contribuir, pero sus aportes deben conservar una visión común. La colaboración no consiste en acumular piezas, sino en construir soluciones compatibles, comprensibles y alineadas con un mismo propósito. La eficiencia no proviene de trabajar más rápido de manera aislada. Proviene de reducir decisiones repetitivas, evitar retrabajos, reutilizar soluciones validadas y ofrecer caminos claros para el montaje. La velocidad sostenible es una consecuencia de la claridad, la coherencia y el aprendizaje acumulado. La inteligencia artificial será utilizada como amplificador de las capacidades del equipo. No deberá producir soluciones arbitrarias o desconectadas, sino trabajar sobre patrones, criterios y activos de conocimiento previamente definidos y validados. Cada patrón de CAPS deberá responder a una necesidad real, explicar el problema que resuelve, establecer sus condiciones de uso y permitir su adaptación responsable. Ningún componente tendrá valor únicamente por existir; su valor estará en la utilidad, la claridad y la capacidad de reutilización que aporte al sistema. Nuestro principio rector es: > **Cada curso que construimos mejora el sistema. > Cada mejora del sistema hace que el siguiente curso pueda construirse con mayor claridad, calidad y eficiencia.** No buscamos únicamente producir más cursos. Buscamos convertir al área de producción en una organización que aprende, conserva su conocimiento y amplía continuamente su capacidad para responder a las necesidades de la institución. --- # 2. Contexto estratégico ## 2.1. Punto de partida El área de producción de cursos ha desarrollado soluciones, fragmentos de código, estructuras visuales y prácticas de montaje que permiten responder a diferentes necesidades dentro de Moodle. Este conocimiento representa un activo valioso porque surge de la experiencia directa, de problemas reales y de soluciones que ya han sido utilizadas en cursos. Actualmente, parte de este conocimiento se encuentra organizado como un repositorio de ejemplos técnicos. Allí se incluyen estructuras para presentar listas, lecturas requeridas, recursos complementarios, banners, botones, tarjetas, carruseles y otros elementos utilizados en el montaje de contenidos. Este repositorio constituye un antecedente fundamental para CAPS. Sin embargo, su valor actual depende en gran medida de que las personas conozcan los fragmentos disponibles, comprendan su funcionamiento, sepan cuándo utilizarlos y puedan adaptarlos correctamente a cada curso. El reto, por tanto, no consiste en desechar lo construido, sino en transformarlo en un sistema de conocimiento más claro, accesible, reutilizable y sostenible. ## 2.2. Necesidad institucional El crecimiento de la educación virtual y el aumento de solicitudes para crear, actualizar o transformar cursos exigen que el área de producción pueda responder con mayor capacidad, consistencia y velocidad. Este crecimiento incorpora nuevos retos: - Mayor volumen de cursos y solicitudes simultáneas. - Participación de diferentes perfiles profesionales en el montaje. - Uso creciente de herramientas de inteligencia artificial. - Creación de componentes visuales, contenidos interactivos y scripts. - Necesidad de mantener consistencia entre cursos y programas. - Dependencia del conocimiento y la experiencia de personas específicas. - Repetición de decisiones y soluciones que ya fueron resueltas anteriormente. - Dificultad para identificar qué recursos están vigentes, validados o disponibles para reutilización. Cuando estas condiciones no se gestionan dentro de un marco común, el crecimiento puede producir dispersión, duplicación, variabilidad y retrabajo. Aumentar el número de personas o incorporar nuevas herramientas no garantiza, por sí solo, una mayor capacidad productiva. Desde la perspectiva planteada por Frederick P. Brooks, la complejidad de un sistema no se resuelve únicamente agregando recursos. A medida que aumenta el número de participantes, también aumentan las necesidades de comunicación, coordinación, aprendizaje y alineación. En el contexto de CAPS, esto significa que la capacidad del área no debe depender solamente de trabajar más rápido o sumar más personas. Debe depender de contar con una arquitectura compartida que permita a diferentes perfiles contribuir sin perder coherencia. ## 2.3. Problema estratégico El problema central que CAPS busca atender puede formularse de la siguiente manera: > **El conocimiento necesario para producir cursos existe, pero se encuentra distribuido entre personas, documentos, códigos, herramientas, experiencias y prácticas que todavía no conforman un sistema institucional integrado.** Esta fragmentación tiene varias consecuencias: - Se vuelven a resolver problemas que ya habían sido solucionados. - Las decisiones de montaje pueden variar según la persona responsable. - Los componentes se reutilizan sin conocer siempre sus condiciones de uso. - Las mejoras realizadas en un curso no necesariamente benefician a los siguientes. - El conocimiento puede perderse cuando cambian las personas o los equipos. - La inteligencia artificial puede generar soluciones inconsistentes si no dispone de criterios institucionales. - El tiempo ahorrado durante un montaje puede convertirse posteriormente en correcciones, mantenimiento o retrabajo. Por esta razón, el desafío no es solamente técnico. Es un desafío de arquitectura organizacional, gestión del conocimiento, coordinación interdisciplinaria y evolución de las capacidades del área. ## 2.4. Oportunidad estratégica CAPS representa la oportunidad de transformar la experiencia acumulada en una capacidad institucional. El sistema permitirá pasar: - De fragmentos aislados a patrones documentados. - De soluciones personales a activos institucionales. - De decisiones repetitivas a criterios reutilizables. - De ejemplos técnicos a soluciones con propósito y condiciones de uso. - De conocimiento disperso a un lenguaje común. - De producción reactiva a producción basada en capacidades. - De inteligencia artificial generativa a inteligencia artificial orientada por patrones validados. - De cursos construidos como productos independientes a cursos que alimentan un sistema de aprendizaje organizacional. La oportunidad no consiste únicamente en producir más cursos. Consiste en conseguir que cada nuevo curso requiera menos esfuerzo repetitivo, aproveche mejor el conocimiento disponible y contribuya al fortalecimiento del área. ## 2.5. Respuesta estratégica CAPS se plantea como un framework organizacional para capturar, organizar, validar, reutilizar y evolucionar el conocimiento relacionado con el montaje de cursos. Su función será conectar cuatro dimensiones que actualmente pueden aparecer separadas: **Dimensión pedagógica:** asegura que cada solución responda a una intención de aprendizaje y a una forma adecuada de organizar la experiencia del estudiante. **Dimensión visual:** establece criterios para presentar contenidos de manera clara, coherente, accesible y alineada con la identidad institucional. **Dimensión técnica:** organiza componentes, códigos, configuraciones, scripts y condiciones de funcionamiento dentro de Moodle. **Dimensión de conocimiento:** documenta las decisiones, aprendizajes, criterios de uso, limitaciones y mejoras asociadas a cada solución. CAPS no busca centralizar todas las decisiones en una sola persona ni restringir la creatividad de los participantes. Busca ofrecer un marco común para que la colaboración produzca resultados compatibles, comprensibles y reutilizables. ## 2.6. Propósito estratégico El propósito estratégico de CAPS es: > **Fortalecer la capacidad institucional para diseñar, ensamblar y evolucionar cursos en Moodle mediante patrones compartidos que reduzcan el trabajo repetitivo, preserven la integridad conceptual y conviertan la experiencia del área en conocimiento reutilizable.** Este propósito se traduce en cuatro objetivos generales: 1. Escalar la producción sin perder calidad ni coherencia. 2. Reducir tiempos de montaje y retrabajo mediante la reutilización de soluciones validadas. 3. Transformar el conocimiento individual en una capacidad institucional disponible para diferentes perfiles y proyectos. 4. Orientar el uso de la inteligencia artificial mediante patrones, criterios y activos de conocimiento previamente definidos. ## 2.7. Principio de crecimiento CAPS parte de una idea sencilla: > **El crecimiento sostenible no consiste en hacer más trabajo de la misma manera. Consiste en construir un sistema que aprenda a trabajar mejor.** Por ello, cada solicitud de producción debe generar dos resultados: - Un curso que responda a una necesidad concreta. - Un aprendizaje que pueda fortalecer el sistema. Esta lógica permite que la experiencia no desaparezca al finalizar un proyecto. Cada solución útil puede convertirse en un patrón; cada error puede convertirse en un criterio preventivo; cada innovación puede convertirse en una nueva capacidad disponible para el área. CAPS permitirá que el conocimiento acumulado no sea solamente memoria del trabajo realizado, sino infraestructura para el trabajo futuro. --- # 3. Definición estratégica de CAPS ## 3.1. Definición general **Course Assembly Pattern System — CAPS** es un framework organizacional para estructurar, preservar y reutilizar el conocimiento relacionado con la producción y el montaje de cursos en Moodle. Su propósito es convertir la experiencia acumulada por el área en un sistema compartido de patrones, criterios, componentes y activos de conocimiento que permita producir cursos con mayor coherencia, calidad y eficiencia. CAPS articula las decisiones pedagógicas, visuales, técnicas y organizativas que intervienen en la construcción de un curso. No se limita a conservar soluciones existentes: las contextualiza, documenta, valida y relaciona para que puedan ser comprendidas, reutilizadas y mejoradas. CAPS puede definirse, por tanto, como: > **Un sistema institucional de patrones para orientar el ensamblaje de cursos, capturar el conocimiento generado durante su producción y convertirlo en una capacidad reutilizable del área.** ## 3.2. Naturaleza estratégica CAPS no debe entenderse como un proyecto temporal con un inicio y un cierre definidos. Es una capacidad institucional que se desarrolla progresivamente y se fortalece con cada curso producido. Su naturaleza estratégica se fundamenta en tres ideas: **Primera:** el conocimiento generado durante la producción de cursos tiene valor más allá del proyecto en el que se originó. **Segunda:** la reutilización efectiva requiere algo más que almacenar componentes; exige documentar el problema que resuelven, sus criterios de uso, sus limitaciones y su relación con otras decisiones. **Tercera:** la capacidad de producir más cursos no depende únicamente de incorporar más personas o herramientas, sino de reducir la complejidad de coordinación mediante una arquitectura común. CAPS permite que el crecimiento del área se apoye en conocimiento acumulado y no exclusivamente en esfuerzos individuales. ## 3.3. Qué es CAPS CAPS es: - Un framework para organizar el conocimiento de producción de cursos. - Un lenguaje común entre los perfiles que participan en el montaje. - Un sistema de patrones pedagógicos, visuales, técnicos y de información. - Una estructura para documentar decisiones y soluciones validadas. - Un mecanismo para facilitar la reutilización responsable. - Una base de conocimiento para orientar herramientas de inteligencia artificial. - Una referencia para mantener la integridad conceptual entre diferentes cursos. - Una capacidad institucional que evoluciona mediante el aprendizaje del área. CAPS conecta la experiencia de diseñadores, productores, montadores, expertos pedagógicos y perfiles técnicos dentro de un marco común. Cada área conserva su especialidad, pero sus aportes se integran mediante conceptos y criterios compartidos. ## 3.4. Qué no es CAPS CAPS no es: - Un repositorio de fragmentos de código sin contexto. - Una colección de diseños visuales independientes. - Un manual rígido que obligue a construir todos los cursos de la misma manera. - Una herramienta de software específica. - Un sistema para reemplazar el criterio profesional. - Un conjunto de instrucciones exclusivas para desarrolladores. - Una biblioteca de prompts desconectados de decisiones institucionales. - Un mecanismo de control destinado a restringir la creatividad. - Una solución automática que elimine la necesidad de análisis, validación o colaboración. El repositorio actual constituye un insumo valioso para CAPS, pues contiene estructuras de listas, lecturas, banners, botones, carruseles, recursos embebidos y otros elementos utilizados en Moodle. Sin embargo, esos elementos todavía se presentan principalmente como ejemplos técnicos y requieren convertirse en activos contextualizados dentro de un sistema más amplio. Por tanto, CAPS no sustituye lo existente. Lo organiza, lo amplía y le proporciona una lógica institucional. ## 3.5. Unidad fundamental de CAPS La unidad fundamental de CAPS es el **patrón de montaje de curso**. Un patrón es una solución documentada y reutilizable para una necesidad recurrente dentro de la producción de cursos. No describe solamente cómo se construye un elemento, sino también: - Qué problema resuelve. - Por qué existe. - En qué situaciones debe utilizarse. - En qué situaciones no resulta adecuado. - Qué información requiere. - Qué decisiones pedagógicas, visuales o técnicas incorpora. - Qué componentes pueden implementarlo. - Qué riesgos o limitaciones presenta. - Cómo debe validarse. - Qué aprendizajes se han obtenido durante su aplicación. El patrón actúa como un puente entre la intención y la implementación. Por ejemplo, una lista de lecturas no debe entenderse únicamente como un fragmento de HTML. Dentro de CAPS puede convertirse en un patrón para organizar recursos académicos, diferenciar lecturas obligatorias de recursos complementarios, establecer criterios de identificación visual y asegurar una forma consistente de acceso a los contenidos. El código es una posible implementación del patrón, pero no es el patrón completo. ## 3.6. Elementos que conforman CAPS CAPS reúne diferentes tipos de activos, cada uno con una función específica. ### Patrones Describen soluciones reutilizables para problemas frecuentes de producción o montaje. ### Componentes Son piezas concretas que permiten implementar un patrón. Pueden incluir estructuras HTML, configuraciones de Moodle, elementos visuales, scripts o recursos interactivos. ### Plantillas Son estructuras prediseñadas que facilitan la aplicación de uno o varios patrones en situaciones recurrentes. ### Criterios Son condiciones que orientan una decisión. Pueden estar relacionados con pedagogía, accesibilidad, diseño visual, organización de información, compatibilidad técnica o experiencia del estudiante. ### Decisiones arquitectónicas Registran elecciones que afectan de manera transversal la construcción de cursos. Explican qué se decidió, por qué se tomó la decisión y qué consecuencias tiene. ### Prompts validados Son instrucciones para herramientas de inteligencia artificial que han sido diseñadas y evaluadas para trabajar de acuerdo con los patrones y criterios de CAPS. ### Casos de aplicación Muestran cómo se utilizó un patrón en un curso real, qué adaptaciones fueron necesarias y qué resultados o aprendizajes se obtuvieron. ### Lecciones aprendidas Documentan problemas, errores, restricciones o descubrimientos que deben tenerse en cuenta en futuras implementaciones. Estos activos no deben existir como piezas aisladas. Su valor depende de las relaciones que se establezcan entre ellos. ## 3.7. Alcance de CAPS CAPS abarca el conocimiento necesario para acompañar el montaje y la evolución de cursos en Moodle, particularmente en los siguientes ámbitos: - Organización de secciones y unidades. - Presentación de lecturas y recursos complementarios. - Estructuración de contenidos académicos. - Creación y adaptación de componentes visuales. - Incorporación de elementos interactivos. - Uso de scripts y animaciones dentro de condiciones controladas. - Integración de recursos externos. - Orientaciones para navegación y experiencia de usuario. - Consistencia visual e institucional. - Accesibilidad y comprensión de los contenidos. - Documentación de decisiones de producción. - Reutilización de soluciones entre cursos. - Uso de inteligencia artificial durante el montaje. - Transferencia de conocimiento entre perfiles y proyectos. CAPS no define los contenidos académicos de cada curso ni reemplaza las decisiones curriculares de los expertos. Su alcance se concentra en la forma en que dichos contenidos, recursos y experiencias son organizados, ensamblados y presentados dentro de la plataforma. ## 3.8. Límites del sistema Para conservar claridad, CAPS debe reconocer expresamente sus límites. CAPS no reemplaza: - El modelo pedagógico institucional. - El proceso de diseño curricular. - La responsabilidad académica de profesores y expertos. - Las políticas institucionales de tecnología, seguridad o identidad visual. - Las funciones administrativas de Moodle. - Los procesos formales de aseguramiento de la calidad. - El juicio profesional de quienes participan en la creación de cursos. CAPS debe conectarse con estos sistemas, políticas y responsabilidades, pero no asumir sus funciones. Su papel es actuar como una capa de articulación entre las decisiones institucionales y la producción concreta de los cursos. ## 3.9. Beneficiarios de CAPS Los beneficiarios directos son los perfiles que intervienen en la producción: - Diseñadores instruccionales. - Diseñadores gráficos. - Productores y montadores de cursos. - Desarrolladores o perfiles técnicos. - Expertos en contenidos. - Revisores de calidad. - Coordinadores y responsables del área. - Colaboradores que utilizan herramientas de inteligencia artificial. Cada perfil puede consultar y aportar conocimiento desde su especialidad, sin necesidad de dominar todos los aspectos técnicos del sistema. Los beneficiarios indirectos son: - Los profesores, que reciben cursos mejor estructurados y más fáciles de gestionar. - Los estudiantes, que encuentran experiencias más claras, consistentes y accesibles. - Las unidades académicas, que obtienen una respuesta más eficiente y predecible. - La institución, que conserva y amplía su conocimiento de producción digital. ## 3.10. Propuesta de valor La propuesta de valor de CAPS puede expresarse de la siguiente manera: > **CAPS permite producir cursos con mayor rapidez y coherencia al transformar las soluciones, decisiones y aprendizajes del área en patrones institucionales que pueden ser comprendidos, reutilizados y mejorados.** CAPS aporta valor porque: - Disminuye la repetición de decisiones. - Reduce la dependencia de conocimientos individuales. - Facilita la incorporación de nuevos colaboradores. - Mejora la consistencia entre cursos. - Permite reutilizar soluciones con criterios claros. - Hace visible el conocimiento acumulado. - Reduce retrabajos derivados de soluciones improvisadas. - Facilita una colaboración interdisciplinaria más ordenada. - Proporciona una base confiable para la automatización. - Permite medir el crecimiento de la capacidad del área. ## 3.11. Relación con la integridad conceptual CAPS adopta la integridad conceptual como uno de sus fundamentos. Inspirado en el planteamiento de Frederick P. Brooks, el sistema reconoce que una solución puede ser construida por múltiples personas sin convertirse en una acumulación de decisiones incompatibles. La integridad conceptual no significa uniformidad absoluta ni centralización excesiva. Significa que los diferentes aportes deben responder a una arquitectura común, utilizar un lenguaje compartido y conservar relaciones comprensibles con el conjunto. En CAPS: - Muchas personas pueden crear componentes. - Diferentes áreas pueden proponer patrones. - Las herramientas de inteligencia artificial pueden acelerar tareas. - Los cursos pueden requerir adaptaciones particulares. Sin embargo, todas estas contribuciones deben conservar una visión coherente sobre cómo se organiza, documenta y mejora la producción. La diversidad de aportes fortalece el sistema cuando existe una arquitectura capaz de integrarlos. ## 3.12. Formulación estratégica consolidada CAPS se define finalmente como: > **Una capacidad institucional para organizar y evolucionar el conocimiento de producción de cursos en Moodle mediante patrones que conectan intenciones pedagógicas, decisiones visuales, soluciones técnicas y aprendizajes organizacionales.** Su resultado no es solamente un catálogo de recursos. Su resultado es una forma compartida de pensar, construir y mejorar cursos. CAPS permite que el área pase de depender principalmente de la experiencia individual a operar sobre una memoria institucional activa, estructurada y en evolución. ## 3.13. Fundamentación teórica y trazabilidad conceptual CAPS integra aportes de distintos campos. No adopta de manera literal un único modelo teórico; construye una arquitectura aplicada al montaje de cursos a partir de principios convergentes. ### 3.13.1. Sistemas y lenguajes de patrones La noción de patrón parte de documentar soluciones recurrentes dentro de un contexto, haciendo explícitos el problema, las condiciones, la solución y sus consecuencias. CAPS traslada este razonamiento al montaje de cursos: el patrón no equivale al código ni a la apariencia de un componente, sino al conocimiento reutilizable que permite resolver una necesidad. La tradición iniciada por Christopher Alexander y adaptada posteriormente al diseño de software por Gamma, Helm, Johnson y Vlissides sustenta las siguientes decisiones de CAPS: - Nombrar los patrones desde el problema o resultado. - Documentar contexto, aplicabilidad, restricciones y consecuencias. - Permitir distintas implementaciones para un mismo patrón. - Relacionar patrones para formar soluciones más amplias. - Evitar que una solución particular se presente como universal. ### 3.13.2. Integridad conceptual y complejidad de coordinación Las reflexiones de Frederick P. Brooks fundamentan la necesidad de conservar una visión común cuando múltiples perfiles contribuyen a un sistema. Agregar personas, herramientas o automatizaciones no garantiza por sí solo una mayor capacidad, pues también aumenta la coordinación requerida. CAPS responde mediante: - Un vocabulario compartido. - Principios arquitectónicos. - Una función explícita de arquitectura. - Interfaces de colaboración. - Derechos de decisión diferenciados. - Validación proporcional al riesgo. - Separación entre contribución distribuida y responsabilidad arquitectónica. ### 3.13.3. Gestión y creación de conocimiento organizacional Los planteamientos de Nonaka y Takeuchi sobre creación de conocimiento organizacional respaldan la transformación de experiencia práctica en conocimiento explícito, compartido y reutilizable. Los casos, lecciones aprendidas, decisiones y patrones de CAPS permiten que el conocimiento generado durante el montaje no permanezca exclusivamente en la experiencia de una persona. Las comunidades de práctica descritas por Etienne Wenger aportan la dimensión social: el conocimiento no se conserva únicamente mediante documentos, sino a través de participación, aplicación, discusión y evolución dentro de una práctica compartida. Estas perspectivas sustentan: - La captura de aprendizajes desde proyectos reales. - La documentación progresiva. - La curaduría del conocimiento. - La participación de diferentes especialidades. - La incorporación de nuevos integrantes mediante casos y prácticas comunes. ### 3.13.4. Sistemas de diseño, modularidad y reutilización La separación entre patrón, plantilla, componente e implementación recoge principios de modularidad y sistemas de diseño. Esta distinción permite conservar el propósito aunque cambie la tecnología y evita confundir una decisión de arquitectura con una pieza visual particular. En CAPS, la reutilización no se limita a copiar. Exige reconocer una necesidad semejante, seleccionar un patrón aplicable, respetar sus invariantes, adaptar los elementos permitidos y validar el resultado en el nuevo contexto. ### 3.13.5. Diseño instruccional y experiencia de aprendizaje CAPS reconoce que el montaje materializa decisiones pedagógicas y comunicativas. Por ello, ningún componente debe institucionalizarse únicamente porque resulte atractivo o técnicamente posible. Debe demostrar que organiza la información, orienta al estudiante, favorece la comprensión o apoya una acción pedagógica definida. Esta relación no convierte a CAPS en un modelo de diseño curricular. El framework actúa como capa de traducción entre las intenciones pedagógicas y su ensamblaje dentro de Moodle. ### 3.13.6. Diseño centrado en las personas y accesibilidad Los principios de diseño centrado en las personas y las Pautas de Accesibilidad para el Contenido Web orientan la validación de legibilidad, navegación, adaptabilidad, percepción y operación de los componentes. La accesibilidad se considera un criterio de calidad transversal y no una adaptación posterior. Su aplicación concreta deberá alinearse con las políticas institucionales, el contexto tecnológico de Moodle y los criterios técnicos vigentes adoptados por la institución. ### 3.13.7. Mejora continua y aprendizaje basado en evidencia El ciclo necesidad, consulta, ensamblaje, validación, aprendizaje y evolución aplica una lógica de mejora continua. Los activos avanzan desde candidato hasta validado mediante pruebas proporcionales al riesgo. Las innovaciones se experimentan antes de convertirse en estándar y pueden corregirse, integrarse, reemplazarse o retirarse. Esta lógica sostiene una regla central: > **CAPS no valida un patrón por su atractivo conceptual, sino por su capacidad demostrada para resolver una necesidad recurrente de forma comprensible, reutilizable y sostenible.** ### 3.13.8. Mapa de trazabilidad | Fundamento | Aplicación principal en CAPS | |---|---| | Lenguajes de patrones | Problema, contexto, solución, criterios, consecuencias y relaciones | | Integridad conceptual | Principios, arquitectura común y decisiones transversales | | Complejidad de coordinación | Interfaces claras, responsabilidades y gobernanza proporcional | | Gestión del conocimiento | Patrones, casos, lecciones, curaduría y memoria institucional | | Comunidades de práctica | Contribución especializada, validación distribuida y aprendizaje colectivo | | Modularidad y sistemas de diseño | Distinción entre patrón, plantilla, componente e implementación | | Diseño instruccional | Pertinencia pedagógica y orientación de la experiencia | | Diseño centrado en las personas | Comprensibilidad, usabilidad y adecuación al contexto | | Accesibilidad | Criterios transversales de percepción, operación y comprensión | | Mejora continua | Pilotaje, estados, medición, aprendizaje, versionamiento y retiro | ### 3.13.9. Referencias fundacionales - Alexander, C., Ishikawa, S., Silverstein, M., Jacobson, M., Fiksdahl-King, I. y Angel, S. (1977). *A Pattern Language: Towns, Buildings, Construction*. Oxford University Press. - Brooks, F. P. (1995). *The Mythical Man-Month: Essays on Software Engineering*. Anniversary Edition. Addison-Wesley. - Gamma, E., Helm, R., Johnson, R. y Vlissides, J. (1994). *Design Patterns: Elements of Reusable Object-Oriented Software*. Addison-Wesley. - International Organization for Standardization. (2019). *ISO 9241-210:2019. Ergonomics of human-system interaction — Part 210: Human-centred design for interactive systems*. - Nonaka, I. y Takeuchi, H. (1995). *The Knowledge-Creating Company: How Japanese Companies Create the Dynamics of Innovation*. Oxford University Press. - Wenger, E. (1998). *Communities of Practice: Learning, Meaning, and Identity*. Cambridge University Press. - World Wide Web Consortium. (2023). *Web Content Accessibility Guidelines (WCAG) 2.2*. W3C Recommendation. Estas referencias constituyen una base inicial. La validación especializada podrá ampliar o ajustar el marco según el modelo pedagógico, las políticas institucionales y las condiciones tecnológicas aplicables. --- # 4. Marco conceptual de CAPS ## 4.1. Propósito del marco conceptual CAPS integra conocimientos provenientes de diferentes disciplinas: pedagogía, diseño instruccional, diseño visual, producción multimedia, desarrollo técnico, gestión de información e inteligencia artificial. Cada disciplina utiliza conceptos y métodos propios. Por ello, antes de definir procesos, responsabilidades o herramientas, es necesario establecer un vocabulario compartido que permita coordinar el trabajo sin eliminar la especialidad de cada perfil. El marco conceptual de CAPS cumple tres funciones: 1. Definir los conceptos fundamentales del sistema. 2. Establecer las relaciones entre los diferentes activos. 3. Proporcionar criterios para clasificar el conocimiento producido por el área. Este marco no pretende crear una taxonomía excesivamente compleja. Busca ofrecer las distinciones mínimas necesarias para que las personas puedan documentar, encontrar, utilizar y mejorar las soluciones de manera consistente. ## 4.2. Curso como sistema ensamblado Dentro de CAPS, un curso no se entiende únicamente como una colección de contenidos alojados en Moodle. Un curso es un sistema ensamblado a partir de decisiones interrelacionadas sobre: - Organización de la información. - Secuencia de aprendizaje. - Navegación. - Presentación visual. - Recursos académicos. - Actividades e interacciones. - Comunicación con el estudiante. - Configuración técnica. - Accesibilidad. - Evaluación y retroalimentación. El montaje consiste en convertir una intención pedagógica y un conjunto de contenidos en una experiencia digital comprensible, navegable y funcional. Por esta razón, ensamblar un curso no equivale simplemente a copiar información dentro de una plataforma. Implica seleccionar, combinar y adaptar soluciones que deben conservar coherencia entre sí. ## 4.3. Patrón El **patrón** es la unidad conceptual principal de CAPS. Un patrón es una solución documentada y reutilizable para una necesidad que aparece de manera recurrente durante la producción o el montaje de cursos. Un patrón responde, como mínimo, a las siguientes preguntas: - ¿Qué necesidad resuelve? - ¿En qué contexto aparece? - ¿Qué resultado busca producir? - ¿Qué criterios deben respetarse? - ¿Cuándo resulta apropiado utilizarlo? - ¿Cuándo no debe utilizarse? - ¿Qué elementos se necesitan para implementarlo? - ¿Cómo se comprueba que funciona correctamente? - ¿Qué adaptaciones admite? - ¿Qué aprendizajes existen sobre su utilización? Un patrón no es una instrucción mecánica ni una solución universal. Es una forma validada de abordar un problema recurrente, conservando suficiente flexibilidad para adaptarse a distintos cursos. ### Ejemplo conceptual **Necesidad:** presentar las lecturas de una unidad de manera clara. **Patrón:** organización de lecturas requeridas y recursos complementarios. El patrón puede definir: - La separación entre recursos obligatorios y opcionales. - La información bibliográfica mínima. - La identificación del tipo de recurso. - La forma de acceso. - Los criterios de legibilidad y accesibilidad. - La cantidad recomendable de información visible. - Las condiciones para abrir recursos externos. El fragmento de código que representa visualmente las lecturas sería solamente una implementación de ese patrón. ## 4.4. Tipos de patrones CAPS puede organizar inicialmente sus patrones en cuatro categorías. Estas categorías no representan áreas aisladas; frecuentemente un patrón combinará decisiones de varias de ellas. ### Patrón pedagógico Resuelve una necesidad relacionada con la experiencia de aprendizaje. Puede orientar, por ejemplo: - La presentación de objetivos. - La secuencia de actividades. - La activación de conocimientos previos. - La organización de recursos obligatorios y complementarios. - La formulación de orientaciones para una actividad. - La comunicación de criterios de evaluación. ### Patrón de organización de información Resuelve una necesidad relacionada con la estructura, jerarquía o navegación del contenido. Puede orientar: - La organización de unidades y secciones. - La jerarquía de títulos. - La presentación de cronogramas. - La agrupación de recursos. - La navegación entre contenidos. - La identificación de información prioritaria. ### Patrón visual Resuelve una necesidad de representación y comunicación gráfica. Puede definir: - Jerarquías visuales. - Uso de iconografía. - Aplicación de colores institucionales. - Estructura de tarjetas, banners o carruseles. - Comportamiento adaptable en diferentes pantallas. - Tratamiento visual de alertas, instrucciones y recursos. ### Patrón técnico Resuelve una necesidad de funcionamiento o integración dentro de Moodle. Puede orientar: - Inserción de recursos externos. - Uso de código HTML. - Aplicación de estilos. - Incorporación controlada de scripts. - Integración de contenido interactivo. - Compatibilidad entre navegadores y dispositivos. - Restricciones técnicas de la plataforma. Estas cuatro categorías permiten clasificar los patrones sin fragmentar el curso. La solución final debe conservar una relación coherente entre intención pedagógica, organización, presentación visual y funcionamiento técnico. ## 4.5. Componente Un **componente** es una pieza concreta y reutilizable que permite implementar uno o varios patrones. Puede ser: - Un bloque de información. - Una tarjeta. - Una lista. - Un banner. - Un botón. - Un carrusel. - Una estructura HTML. - Una configuración de Moodle. - Una pieza gráfica. - Un recurso interactivo. - Un script autorizado. - Una combinación de varios elementos. El componente responde principalmente a la pregunta: **¿Con qué pieza puede implementarse la solución?** El patrón, en cambio, responde a: **¿Qué problema se está resolviendo y bajo qué criterios?** Un mismo patrón puede implementarse mediante diferentes componentes. De igual forma, un componente puede participar en distintos patrones. Por ejemplo, una tarjeta puede utilizarse para presentar una lectura, un profesor, una actividad o una recomendación. Sin embargo, el propósito, la información requerida y los criterios de uso serán distintos en cada caso. Por ello, CAPS no debe clasificar los componentes solamente por su apariencia. Debe relacionarlos con los patrones que permiten implementar. ## 4.6. Plantilla Una **plantilla** es una estructura prediseñada que organiza varios componentes y aplica uno o más patrones para atender una situación recurrente. La plantilla reduce decisiones repetitivas y ofrece un punto de partida consistente. Puede existir, por ejemplo: - Una plantilla para la página de bienvenida. - Una plantilla para una unidad de aprendizaje. - Una plantilla para presentar lecturas. - Una plantilla para la sección de evaluación. - Una plantilla para la presentación del profesor. - Una plantilla para cursos de una misma tipología. La plantilla no debe convertirse en una estructura rígida que se copie sin análisis. Debe indicar: - Qué elementos son obligatorios. - Qué elementos son opcionales. - Qué aspectos pueden modificarse. - Qué criterios no deben alterarse. - Qué patrones incorpora. - En qué situaciones es adecuada. El patrón conserva el conocimiento de la solución; la plantilla facilita su aplicación repetida. ## 4.7. Implementación La **implementación** es la materialización concreta de un patrón o una plantilla dentro de una tecnología, plataforma o curso específico. Puede consistir en: - Código HTML. - Estilos CSS. - Configuraciones de Moodle. - Scripts. - Imágenes. - Recursos H5P. - Bloques nativos de la plataforma. - Herramientas externas. - Combinaciones de los elementos anteriores. CAPS distingue entre patrón e implementación porque las tecnologías cambian con mayor rapidez que las necesidades que resuelven. Un patrón para presentar recursos académicos puede permanecer vigente, aunque cambie: - El código utilizado. - La versión de Moodle. - El sistema visual institucional. - La herramienta de producción. - El mecanismo de interacción. Esta distinción evita que el conocimiento institucional quede atado exclusivamente a una solución técnica particular. ## 4.8. Activo de conocimiento Un **activo de conocimiento** es cualquier recurso documentado que conserva, comunica o permite reutilizar el conocimiento generado durante la producción de cursos. Los activos de conocimiento de CAPS pueden incluir: - Patrones. - Componentes. - Plantillas. - Criterios. - Guías. - Decisiones arquitectónicas. - Casos de aplicación. - Lecciones aprendidas. - Prompts validados. - Listas de comprobación. - Ejemplos y contraejemplos. - Resultados de pruebas. - Restricciones técnicas documentadas. Todo patrón es un activo de conocimiento, pero no todo activo de conocimiento es un patrón. Por ejemplo, una lección aprendida sobre una incompatibilidad de Moodle es un activo de conocimiento. Puede contribuir posteriormente a modificar un patrón o crear un criterio técnico, pero no constituye por sí sola un patrón completo. ## 4.9. Criterio Un **criterio** es una condición que permite orientar o evaluar una decisión de montaje. Los criterios responden a preguntas como: - ¿Esta solución es pedagógicamente pertinente? - ¿La información se comprende con facilidad? - ¿El componente es accesible? - ¿Funciona correctamente en Moodle? - ¿Respeta la identidad visual? - ¿Puede reutilizarse? - ¿Su mantenimiento es razonable? - ¿Mejora realmente el tiempo de montaje? - ¿La solución introduce una complejidad innecesaria? Los criterios pueden ser: ### Obligatorios Deben cumplirse porque se relacionan con políticas, accesibilidad, seguridad, funcionamiento o identidad institucional. ### Recomendados Representan buenas prácticas que deberían aplicarse salvo que exista una razón justificada para no hacerlo. ### Contextuales Dependen del tipo de curso, público, contenido o necesidad específica. Los criterios permiten que la validación no dependa únicamente de preferencias individuales. ## 4.10. Decisión arquitectónica Una **decisión arquitectónica** registra una elección que afecta de manera transversal varios patrones, componentes o cursos. Debe indicar: - Qué se decidió. - Qué problema motivó la decisión. - Qué alternativas se consideraron. - Por qué se eligió una alternativa. - Qué consecuencias produce. - En qué condiciones debe revisarse. Son ejemplos de decisiones arquitectónicas: - Utilizar una estructura común de navegación. - Limitar determinados scripts. - Establecer un sistema compartido de iconografía. - Priorizar componentes nativos de Moodle frente a herramientas externas. - Adoptar un criterio común para abrir recursos. - Definir niveles de personalización visual. Documentar estas decisiones protege la integridad conceptual de CAPS. También evita que el equipo repita discusiones sin conocer las razones que originaron una elección anterior. ## 4.11. Caso de aplicación Un **caso de aplicación** documenta la utilización de un patrón dentro de un curso o proyecto concreto. Su propósito no es solamente mostrar el resultado final. Debe explicar: - Qué necesidad existía. - Qué patrón se utilizó. - Qué adaptaciones fueron necesarias. - Qué componentes se emplearon. - Qué dificultades aparecieron. - Qué resultados se obtuvieron. - Qué podría mejorarse. Los casos permiten comprobar que los patrones funcionan en situaciones reales. También muestran que una solución puede adaptarse sin perder sus principios fundamentales. ## 4.12. Lección aprendida Una **lección aprendida** es un conocimiento derivado de la experiencia que puede mejorar trabajos futuros. Puede originarse en: - Un error. - Una incompatibilidad técnica. - Una corrección solicitada. - Una dificultad de comprensión. - Una prueba con usuarios. - Una mejora exitosa. - Una adaptación inesperada. - Un uso inadecuado de un componente. - Una limitación de la plataforma. La lección aprendida debe convertirse en una acción dentro de CAPS. Puede conducir a: - Crear un nuevo patrón. - Modificar un patrón existente. - Incorporar un criterio. - Actualizar una plantilla. - Retirar un componente. - Mejorar un prompt. - Documentar una restricción. Una lección que solamente se comenta, pero no modifica el sistema, continúa siendo conocimiento informal. ## 4.13. Prompt validado Un **prompt validado** es una instrucción estructurada para una herramienta de inteligencia artificial que ha sido revisada y probada dentro de un contexto de uso específico. No es solamente una frase que produjo un buen resultado una vez. Debe indicar: - Qué tarea realiza. - Qué información de entrada necesita. - Qué patrón o criterio debe respetar. - Qué formato de salida se espera. - Qué aspectos requieren revisión humana. - Qué limitaciones se han identificado. - Qué versión del prompt se encuentra vigente. Los prompts validados permiten que la inteligencia artificial trabaje sobre el conocimiento institucional y no únicamente sobre instrucciones improvisadas. La IA puede acelerar la producción de variaciones, borradores, estructuras o implementaciones. Sin embargo, la responsabilidad por la pertinencia, coherencia y calidad de los resultados continúa siendo humana. ## 4.14. Validación La **validación** es el proceso mediante el cual se determina si un activo puede incorporarse, mantenerse o reutilizarse dentro de CAPS. Validar no significa únicamente comprobar que un código funciona. Dependiendo del activo, la validación puede considerar: - Pertinencia pedagógica. - Claridad de la información. - Coherencia visual. - Accesibilidad. - Compatibilidad técnica. - Facilidad de mantenimiento. - Posibilidad de reutilización. - Seguridad. - Cumplimiento institucional. - Evidencia obtenida en su aplicación. Un activo puede funcionar técnicamente y, aun así, no ser adecuado como patrón institucional. Para formar parte de CAPS debe aportar una solución comprensible, sostenible y coherente con el sistema. ## 4.15. Reutilización La **reutilización** consiste en aplicar conocimiento previamente validado a una nueva necesidad, evitando reconstruir una solución desde cero. No debe confundirse con copiar de manera automática. Reutilizar implica: 1. Reconocer una necesidad similar. 2. Identificar el patrón correspondiente. 3. Revisar sus condiciones de uso. 4. Seleccionar una implementación compatible. 5. Adaptar los elementos permitidos. 6. Validar el resultado en el nuevo contexto. 7. Documentar cualquier aprendizaje relevante. CAPS busca una reutilización consciente. Una solución se reutiliza porque sus principios continúan siendo pertinentes, no solamente porque está disponible. ## 4.16. Adaptación y variación Una **adaptación** es una modificación realizada para aplicar un patrón en un contexto particular sin alterar su propósito fundamental. Una **variación** es una versión reconocida de un patrón o componente que responde a una condición recurrente distinta. Por ejemplo, un patrón de presentación de lecturas puede contar con: - Una variación básica en forma de lista. - Una variación visual mediante tarjetas. - Una variación compacta para cursos con numerosos recursos. - Una variación accesible para contextos específicos. Documentar variaciones evita la proliferación de soluciones aparentemente diferentes que, en realidad, responden al mismo problema. La adaptación debe conservar la integridad conceptual. Cuando una modificación cambia el propósito, los criterios o el comportamiento esencial, puede ser necesario definir un nuevo patrón. ## 4.17. Integridad conceptual La **integridad conceptual** es la coherencia que permite que múltiples contribuciones formen parte de un mismo sistema. Dentro de CAPS significa que: - Los patrones comparten una lógica común. - Los términos se utilizan de manera consistente. - Los componentes responden a propósitos documentados. - Las decisiones no se contradicen entre sí. - Las variaciones conservan los principios esenciales. - La inteligencia artificial opera con criterios institucionales. - Las innovaciones se integran sin fragmentar el sistema. La integridad conceptual no exige que todos los cursos sean idénticos. Exige que las diferencias sean intencionales, justificables y comprensibles. Este principio permite aplicar a CAPS una de las ideas centrales de Brooks: un sistema construido por muchas personas necesita una visión coherente para no convertirse en una acumulación de piezas desconectadas. ## 4.18. Relación entre los conceptos Los conceptos fundamentales de CAPS se relacionan de la siguiente manera: **Una necesidad recurrente** origina la identificación de un **patrón**. El patrón establece el propósito, el contexto y los criterios de la solución. Una **plantilla** facilita la aplicación repetida de uno o varios patrones. Los **componentes** proporcionan las piezas necesarias para implementar la solución. La **implementación** materializa esas piezas dentro de Moodle o de una tecnología específica. Los **criterios** orientan y permiten validar las decisiones. Las **decisiones arquitectónicas** mantienen coherencia entre distintos patrones y soluciones. Los **casos de aplicación** muestran cómo se utiliza el conocimiento en cursos reales. Las **lecciones aprendidas** permiten corregir y evolucionar el sistema. Los **prompts validados** ayudan a utilizar inteligencia artificial de acuerdo con los patrones y criterios establecidos. Todos estos elementos constituyen **activos de conocimiento** de CAPS. ## 4.19. Modelo conceptual mínimo Para evitar que CAPS se vuelva innecesariamente complejo, todo conocimiento nuevo puede clasificarse inicialmente mediante cinco preguntas: 1. **¿Qué problema recurrente estamos resolviendo?** Permite identificar el patrón. 2. **¿Qué criterios debe cumplir la solución?** Permite establecer sus condiciones de calidad. 3. **¿Qué piezas permiten construirla?** Permite identificar componentes y plantillas. 4. **¿Cómo se implementa en Moodle?** Permite documentar código, configuración o integración. 5. **¿Qué aprendimos al utilizarla?** Permite actualizar casos, decisiones y lecciones aprendidas. Si una solución no puede responder con claridad estas preguntas, todavía no se encuentra suficientemente madura para convertirse en un patrón institucional. ## 4.20. Síntesis del marco conceptual CAPS organiza el conocimiento desde el problema hacia la solución, y no desde el código hacia el uso. Su lógica fundamental es: > **El patrón conserva el conocimiento de la solución; la plantilla facilita su aplicación; el componente permite construirla; la implementación la materializa; y la experiencia permite mejorarla.** Esta distinción permite que CAPS evolucione sin perder su propósito cuando cambien las herramientas, las tecnologías o las personas que participan en la producción. El marco conceptual establece así un lenguaje común para documentar, discutir y mejorar el montaje de cursos con mayor precisión. --- # 5. Principios arquitectónicos de CAPS ## 5.1. Propósito de los principios Los principios arquitectónicos establecen la forma en que CAPS debe construirse, utilizarse y evolucionar. No son procedimientos detallados ni instrucciones técnicas. Son criterios de decisión que permiten mantener una dirección común cuando aparecen nuevas necesidades, propuestas, tecnologías o formas de trabajo. Su función es evitar que CAPS crezca como una acumulación de componentes, códigos y documentos sin relación entre sí. Los principios se inspiran especialmente en las reflexiones de Frederick P. Brooks sobre la integridad conceptual, la complejidad, la coordinación de equipos y la ausencia de soluciones tecnológicas milagrosas. En el contexto de CAPS, estas ideas se traducen en una premisa general: > **La capacidad de producir cursos de manera sostenible depende más de la claridad y coherencia del sistema que de la cantidad de herramientas, componentes o personas involucradas.** CAPS adopta ocho principios arquitectónicos fundamentales. ## 5.2. Principio 1: Integridad conceptual ### Declaración **Todas las contribuciones deben formar parte de una visión común del sistema.** CAPS puede recibir aportes de múltiples personas, disciplinas y herramientas. Sin embargo, la diversidad de contribuciones no debe producir una colección de soluciones incompatibles. La integridad conceptual implica que los patrones, componentes, plantillas, criterios y decisiones deben conservar relaciones comprensibles entre sí. No significa que todos los cursos deban verse o funcionar exactamente igual. Significa que las diferencias deben ser intencionales, justificadas y coherentes con el propósito del sistema. ### Aplicación en CAPS Este principio exige: - Utilizar un lenguaje conceptual compartido. - Relacionar cada componente con un patrón. - Evitar soluciones aisladas que no puedan explicarse dentro del framework. - Registrar las decisiones que afecten varios cursos o componentes. - Revisar que las nuevas propuestas no contradigan criterios existentes. - Mantener coherencia entre lo pedagógico, lo visual y lo técnico. - Definir claramente qué elementos son comunes y cuáles pueden variar. ### Pregunta de validación **¿Esta propuesta fortalece la visión común de CAPS o introduce una lógica paralela que fragmenta el sistema?** ## 5.3. Principio 2: Simplicidad antes que complejidad ### Declaración **CAPS debe introducir solamente la complejidad necesaria para resolver problemas reales.** La complejidad no siempre puede eliminarse. Organizar contenidos, integrar herramientas, atender distintos tipos de cursos y coordinar varias disciplinas son actividades inherentemente complejas. Sin embargo, el sistema no debe añadir complejidad innecesaria mediante: - Clasificaciones excesivas. - Procesos difíciles de comprender. - Documentación repetitiva. - Variaciones sin justificación. - Herramientas que duplican funciones. - Automatizaciones difíciles de mantener. - Componentes sofisticados para necesidades simples. CAPS debe distinguir entre la complejidad esencial del montaje de cursos y la complejidad accidental producida por decisiones, herramientas o procedimientos poco claros. ### Aplicación en CAPS Este principio exige: - Comenzar con un modelo conceptual mínimo. - Crear nuevos tipos de activos solamente cuando exista una necesidad recurrente. - Preferir soluciones comprensibles frente a soluciones excesivamente sofisticadas. - Priorizar componentes nativos o estables cuando resulten suficientes. - Evitar automatizar procesos que todavía no han sido comprendidos. - Retirar elementos que hayan perdido utilidad. - Documentar únicamente la información necesaria para reutilizar y mejorar una solución. ### Pregunta de validación **¿Esta solución resuelve una necesidad real o está aumentando la complejidad del sistema sin aportar un beneficio proporcional?** ## 5.4. Principio 3: El patrón precede a la implementación ### Declaración **Antes de seleccionar o construir una solución técnica, debe comprenderse el problema que se quiere resolver.** CAPS se organiza desde las necesidades hacia las soluciones, no desde el código hacia los posibles usos. Un componente visualmente atractivo o un script funcional no constituye por sí mismo un patrón. Para incorporarlo al sistema es necesario identificar: - Qué problema resuelve. - En qué contexto resulta útil. - Qué criterios debe cumplir. - Qué riesgos o limitaciones presenta. - Qué alternativas existen. - Cómo debe validarse. Esta separación permite que el conocimiento permanezca vigente aunque cambien Moodle, las herramientas de diseño, los lenguajes o las tecnologías utilizadas. ### Aplicación en CAPS Este principio exige: - Definir el propósito antes de crear el componente. - Documentar el patrón independientemente de su código. - Permitir diferentes implementaciones para un mismo patrón. - No convertir una herramienta específica en el centro del sistema. - Revisar periódicamente si una implementación sigue siendo la más adecuada. - Conservar el conocimiento funcional cuando una tecnología sea reemplazada. ### Pregunta de validación **¿Estamos resolviendo una necesidad documentada o buscando una justificación para utilizar una herramienta o componente disponible?** ## 5.5. Principio 4: Reutilizar con criterio, no copiar automáticamente ### Declaración **La reutilización debe conservar el propósito del patrón y reconocer las condiciones del nuevo contexto.** CAPS busca disminuir tiempos de montaje mediante activos reutilizables. Sin embargo, reutilizar no significa copiar una solución sin análisis. Cada curso puede presentar diferencias relacionadas con: - Público objetivo. - Tipo de contenido. - Nivel de formación. - Duración. - Metodología. - Requisitos de accesibilidad. - Cantidad de recursos. - Necesidades de interacción. - Restricciones técnicas. Una solución validada debe revisarse antes de ser aplicada en un nuevo contexto. ### Aplicación en CAPS Este principio exige: - Consultar las condiciones de uso de cada patrón. - Diferenciar elementos obligatorios, adaptables y opcionales. - Evitar personalizaciones que alteren el propósito fundamental. - Documentar las variaciones recurrentes. - Validar nuevamente la solución después de adaptarla. - Convertir las adaptaciones útiles en conocimiento disponible para otros cursos. ### Pregunta de validación **¿Estamos reutilizando el conocimiento de una solución o solamente copiando su apariencia?** ## 5.6. Principio 5: El conocimiento pertenece al sistema ### Declaración **Las decisiones y aprendizajes relevantes no deben depender únicamente de la memoria de las personas.** La experiencia individual es indispensable, pero se convierte en capacidad institucional solamente cuando puede ser comprendida, utilizada y mejorada por otros. CAPS debe preservar: - Las razones detrás de las decisiones. - Los criterios de uso. - Las restricciones conocidas. - Las soluciones probadas. - Los errores identificados. - Las adaptaciones realizadas. - Los resultados obtenidos. Este principio no pretende eliminar la autoría ni desconocer el aporte de las personas. Busca evitar que la organización pierda conocimiento cuando cambien los equipos, las responsabilidades o los proyectos. ### Aplicación en CAPS Este principio exige: - Documentar decisiones relevantes durante el trabajo. - Identificar responsables o autores de los activos. - Evitar que las soluciones existan únicamente en conversaciones privadas. - Incorporar las lecciones aprendidas al sistema. - Facilitar que el conocimiento pueda localizarse y comprenderse. - Diseñar procesos de transferencia para nuevos integrantes. - Reconocer y conservar la evolución histórica de los patrones. ### Pregunta de validación **¿Otra persona podría comprender y reutilizar esta solución sin depender exclusivamente de quien la creó?** ## 5.7. Principio 6: La colaboración requiere límites e interfaces claras ### Declaración **Muchas personas pueden contribuir cuando está claro qué pueden modificar, qué deben conservar y cómo se integran sus aportes.** La colaboración no se consigue únicamente permitiendo que todas las personas intervengan sobre todos los elementos. Cuando las responsabilidades, límites y relaciones no son claras, aumentan: - Las necesidades de coordinación. - Las decisiones contradictorias. - Los errores de integración. - Los tiempos de revisión. - La dependencia de conversaciones informales. - El retrabajo. CAPS debe ofrecer caminos seguros para que diseñadores, productores, expertos pedagógicos, montadores y perfiles técnicos aporten desde su especialidad. ### Aplicación en CAPS Este principio exige: - Definir qué tipo de conocimiento aporta cada perfil. - Establecer criterios comunes de documentación. - Diferenciar elementos de libre adaptación y elementos controlados. - Permitir contribuciones sin exigir que todos dominen el sistema completo. - Definir puntos mínimos de revisión. - Facilitar la integración mediante plantillas, contratos o fichas comunes. - Reducir las dependencias innecesarias entre personas. La revisión no debe convertirse en una barrera burocrática. Debe concentrarse en las decisiones que realmente pueden afectar la coherencia, la calidad o el funcionamiento del sistema. ### Pregunta de validación **¿Las personas pueden contribuir con autonomía sin comprometer la coherencia del conjunto?** ## 5.8. Principio 7: La automatización y la inteligencia artificial deben operar sobre conocimiento validado ### Declaración **La inteligencia artificial debe amplificar el sistema, no sustituir su arquitectura.** Las herramientas de inteligencia artificial pueden reducir tiempos, generar variaciones, estructurar contenidos, adaptar componentes y apoyar tareas repetitivas. Sin embargo, si trabajan sin criterios institucionales, también pueden: - Crear soluciones inconsistentes. - Multiplicar código innecesario. - Introducir errores técnicos. - Ignorar restricciones de Moodle. - Producir estilos visuales incompatibles. - Generar resultados difíciles de mantener. - Repetir decisiones que ya habían sido resueltas. CAPS debe proporcionar a la inteligencia artificial el contexto necesario para trabajar de acuerdo con los patrones, criterios y decisiones del área. ### Aplicación en CAPS Este principio exige: - Utilizar prompts vinculados con patrones concretos. - Proporcionar criterios y restricciones explícitas. - Definir formatos de entrada y salida. - Mantener revisión humana sobre los resultados. - Documentar las limitaciones de cada automatización. - Validar los resultados antes de incorporarlos al catálogo. - Evitar que la IA cree nuevos estándares de manera implícita. - Convertir los usos exitosos en prompts y flujos reutilizables. La automatización debe aplicarse después de comprender y estabilizar el proceso que pretende apoyar. ### Pregunta de validación **¿La herramienta está aplicando conocimiento institucional o está tomando decisiones que CAPS todavía no ha definido?** ## 5.9. Principio 8: Evolución incremental basada en experiencia ### Declaración **CAPS debe crecer mediante ciclos pequeños de aplicación, validación y aprendizaje.** No existe una solución única que permita diseñar desde el comienzo un sistema completo y definitivo para todos los cursos. CAPS deberá evolucionar conforme se utilice en proyectos reales. Esta evolución debe ser deliberada, documentada y gradual. En lugar de intentar anticipar todas las necesidades, el sistema debe: 1. Identificar un problema frecuente. 2. Proponer una solución inicial. 3. Aplicarla en un contexto real. 4. Evaluar su funcionamiento. 5. Incorporar los aprendizajes. 6. Extenderla únicamente cuando exista evidencia suficiente. Este principio se relaciona con la advertencia de Brooks sobre la ausencia de “balas de plata”. Ninguna tecnología, metodología o automatización resolverá por sí sola todos los desafíos de producción. La mejora sostenible será el resultado de numerosas decisiones coherentes y acumulativas. ### Aplicación en CAPS Este principio exige: - Comenzar con los patrones de mayor uso o impacto. - Probar antes de estandarizar. - Trabajar con versiones iniciales suficientemente útiles. - Permitir que los patrones evolucionen. - Registrar los cambios importantes. - Retirar o reemplazar soluciones obsoletas. - Utilizar los cursos reales como fuente de aprendizaje. - Medir tanto la eficiencia como la calidad y el mantenimiento. ### Pregunta de validación **¿Esta propuesta ha sido aprendida y probada suficientemente para convertirse en una práctica compartida?** ## 5.10. Relación entre los principios Los ocho principios funcionan como un conjunto y no deben interpretarse de forma aislada. La **integridad conceptual** mantiene una visión común. La **simplicidad** impide que esa visión se convierta en una estructura innecesariamente compleja. La prioridad del **patrón sobre la implementación** protege el conocimiento frente a los cambios tecnológicos. La **reutilización con criterio** permite reducir tiempos sin aplicar soluciones fuera de contexto. El principio de que **el conocimiento pertenece al sistema** convierte la experiencia en capacidad institucional. Las **interfaces claras de colaboración** permiten que diferentes perfiles contribuyan sin aumentar excesivamente la coordinación. La **automatización orientada por conocimiento validado** permite utilizar inteligencia artificial de manera responsable. La **evolución incremental** asegura que CAPS crezca a partir de evidencia y aprendizaje reales. En conjunto, estos principios buscan equilibrar: - Coherencia y flexibilidad. - Velocidad y sostenibilidad. - Estandarización e innovación. - Autonomía y coordinación. - Tecnología y criterio profesional. - Reutilización y adaptación. ## 5.11. Filtro arquitectónico para nuevas propuestas Antes de incorporar un nuevo patrón, componente, plantilla, herramienta o automatización, CAPS deberá responder las siguientes preguntas: 1. ¿Qué problema real y recurrente resuelve? 2. ¿Se relaciona con un patrón existente o requiere uno nuevo? 3. ¿Respeta la integridad conceptual del sistema? 4. ¿Es la solución más simple que puede resolver adecuadamente la necesidad? 5. ¿Puede ser comprendida y utilizada por otras personas? 6. ¿Sus condiciones, riesgos y limitaciones están documentados? 7. ¿Puede mantenerse y evolucionar sin generar una dependencia innecesaria? 8. ¿Ha sido probada o existe una forma concreta de validarla? 9. ¿Produce un beneficio verificable en calidad, claridad, reutilización o tiempo de montaje? 10. ¿El aprendizaje derivado de su uso podrá incorporarse nuevamente a CAPS? Una propuesta no necesita responder perfectamente todas las preguntas desde su primera versión. Sin embargo, debe contar con suficiente claridad para avanzar como experimento, candidato o activo validado. ## 5.12. Síntesis de los principios arquitectónicos Los principios arquitectónicos de CAPS pueden resumirse en la siguiente declaración: > **CAPS debe crecer como un sistema simple, coherente y aprendiente, en el que múltiples personas y herramientas puedan contribuir mediante patrones compartidos, sin perder la integridad conceptual ni convertir la velocidad inmediata en complejidad futura.** Estos principios constituyen la referencia para diseñar los pilares, los procesos, la gobernanza y los mecanismos de evolución del framework. --- # 6. Arquitectura de pilares de CAPS ## 6.1. Propósito de la arquitectura La arquitectura de CAPS organiza las grandes capacidades necesarias para convertir el conocimiento de producción de cursos en un sistema institucional coherente, reutilizable y evolutivo. Los pilares no representan departamentos, cargos ni etapas consecutivas. Tampoco deben entenderse como módulos independientes. Son dimensiones complementarias que intervienen en la construcción de los patrones y en su aplicación dentro de los cursos. Un patrón puede pertenecer principalmente a un pilar, pero normalmente estará relacionado con varios. Por ejemplo, un patrón para presentar lecturas responde a una necesidad pedagógica, organiza información, utiliza componentes visuales, requiere una implementación técnica y genera conocimiento que debe documentarse. La arquitectura de CAPS se compone de seis pilares: 1. Arquitectura de conocimiento. 2. Arquitectura de producción. 3. Arquitectura pedagógica. 4. Arquitectura de experiencia y comunicación visual. 5. Arquitectura técnica y de componentes. 6. Arquitectura de automatización e inteligencia artificial. Estos pilares se encuentran sostenidos por una capacidad transversal: **gobernanza y evolución**. ## 6.2. Estructura general CAPS puede comprenderse como un sistema de tres niveles. ### Nivel estratégico Define el propósito, los principios y los criterios institucionales que deben conservarse. En este nivel se encuentran: - El manifiesto. - La definición estratégica. - Los principios arquitectónicos. - Las decisiones transversales. - Los criterios de calidad y coherencia. ### Nivel de conocimiento Organiza los patrones y activos que traducen los principios estratégicos en soluciones reutilizables. En este nivel se encuentran: - Patrones. - Criterios. - Plantillas. - Casos de aplicación. - Decisiones arquitectónicas. - Lecciones aprendidas. - Prompts validados. ### Nivel de aplicación Materializa el conocimiento en cursos, componentes, configuraciones y flujos concretos de trabajo. En este nivel se encuentran: - Componentes visuales. - Código y configuraciones. - Estructuras de Moodle. - Recursos interactivos. - Implementaciones de plantillas. - Automatizaciones. - Cursos construidos. La arquitectura evita que CAPS comience directamente por el nivel de aplicación. Los componentes y códigos deben estar respaldados por conocimiento documentado, y ese conocimiento debe responder a una dirección estratégica. ## 6.3. Pilar 1: Arquitectura de conocimiento ### Propósito La arquitectura de conocimiento permite capturar, organizar, relacionar y preservar lo que el área aprende durante la producción de cursos. Este pilar convierte la experiencia del equipo en memoria institucional activa. Su objetivo no es almacenar toda la información posible, sino asegurar que el conocimiento relevante pueda encontrarse, comprenderse, reutilizarse y actualizarse. ### Pregunta central **¿Cómo convertimos lo que las personas saben y aprenden en una capacidad disponible para toda el área?** ### Capacidades que comprende - Identificar conocimiento útil generado durante los proyectos. - Convertir soluciones recurrentes en patrones. - Clasificar los activos de manera comprensible. - Relacionar patrones, componentes, plantillas y casos. - Documentar las razones detrás de las decisiones. - Conservar lecciones aprendidas. - Diferenciar activos vigentes, experimentales, obsoletos o retirados. - Facilitar la búsqueda y recuperación de información. - Mantener una historia básica de la evolución del sistema. - Transformar conocimiento tácito en conocimiento compartido. ### Resultados esperados - Un catálogo estructurado de patrones. - Un vocabulario común. - Fichas comprensibles para cada activo. - Casos de aplicación. - Registro de decisiones arquitectónicas. - Lecciones aprendidas incorporadas al sistema. - Relaciones explícitas entre problemas y soluciones. ### Riesgo que busca evitar Este pilar evita que CAPS se convierta en una acumulación de archivos cuyo significado depende de las personas que los crearon. ## 6.4. Pilar 2: Arquitectura de producción ### Propósito La arquitectura de producción organiza la manera en que una solicitud de curso se transforma en una experiencia montada, validada y disponible en Moodle. No busca imponer un procedimiento rígido para todos los proyectos. Busca identificar una estructura común que permita reconocer entradas, decisiones, puntos de validación y resultados. ### Pregunta central **¿Cómo convertimos una solicitud de producción en un curso terminado de manera comprensible, consistente y repetible?** ### Capacidades que comprende - Identificar los tipos frecuentes de solicitudes. - Reconocer la información mínima necesaria para comenzar. - Diferenciar actividades de diseño, preparación, montaje y validación. - Definir entregables intermedios comprensibles. - Detectar dependencias y restricciones antes del montaje. - Utilizar patrones y plantillas en el momento adecuado. - Evitar que cada curso se construya desde cero. - Incorporar controles de calidad sin burocracia excesiva. - Registrar desviaciones y aprendizajes. - Devolver al sistema el conocimiento generado durante el proyecto. ### Resultados esperados - Una visión compartida del ciclo de construcción. - Entradas y salidas definidas. - Puntos mínimos de validación. - Criterios para seleccionar patrones. - Reducción de decisiones repetitivas. - Mayor previsibilidad en los tiempos de montaje. - Información útil para medir capacidad y rendimiento. ### Riesgo que busca evitar Este pilar evita que la producción dependa de secuencias informales, interpretaciones personales o decisiones tardías que generen retrabajo. ## 6.5. Pilar 3: Arquitectura pedagógica ### Propósito La arquitectura pedagógica asegura que los patrones y componentes de CAPS respondan a una intención de aprendizaje y no únicamente a una preferencia visual o posibilidad técnica. CAPS no reemplaza el modelo pedagógico institucional ni el diseño curricular. Su función consiste en traducir esas orientaciones a decisiones concretas de organización y montaje dentro de Moodle. ### Pregunta central **¿Qué propósito de aprendizaje justifica la forma en que organizamos y presentamos cada elemento del curso?** ### Capacidades que comprende - Relacionar componentes con propósitos pedagógicos. - Organizar contenidos según su función dentro del aprendizaje. - Diferenciar información introductoria, conceptual, práctica y evaluativa. - Presentar objetivos, instrucciones y criterios con claridad. - Organizar lecturas requeridas y recursos complementarios. - Facilitar la orientación y autonomía del estudiante. - Evitar sobrecarga de información. - Mantener coherencia entre contenidos, actividades y evaluación. - Reconocer diferentes tipos de experiencias de aprendizaje. - Evaluar si un patrón aporta claridad o distrae del propósito formativo. ### Resultados esperados - Patrones vinculados con necesidades de aprendizaje. - Criterios para organizar contenidos. - Orientaciones para secuencias y jerarquías. - Plantillas que faciliten la comprensión del curso. - Mejor relación entre intención académica y experiencia digital. - Evidencia de que los componentes apoyan el aprendizaje. ### Riesgo que busca evitar Este pilar evita que CAPS se convierta en un sistema centrado en la apariencia o en la tecnología, desconectado de la experiencia educativa. ## 6.6. Pilar 4: Arquitectura de experiencia y comunicación visual ### Propósito Este pilar organiza la manera en que los estudiantes perciben, comprenden y utilizan la información presentada en el curso. Incluye diseño visual, jerarquía, navegación, legibilidad, accesibilidad y consistencia. Su finalidad no es uniformar todos los cursos, sino asegurar que las decisiones visuales ayuden a comprender el contenido y a realizar las acciones esperadas. ### Pregunta central **¿Cómo hacemos que la información y las acciones del curso resulten claras, reconocibles y utilizables?** ### Capacidades que comprende - Establecer jerarquías visuales consistentes. - Diferenciar tipos de información. - Organizar secciones y bloques. - Definir usos apropiados de tarjetas, listas, banners y carruseles. - Aplicar iconografía con significado estable. - Mantener coherencia con la identidad institucional. - Facilitar la navegación. - Diseñar para diferentes tamaños de pantalla. - Incorporar criterios de accesibilidad. - Evitar decoraciones o interacciones que no aporten claridad. - Definir qué elementos pueden personalizarse. - Mantener consistencia sin eliminar la identidad particular de cada curso. ### Resultados esperados - Patrones de presentación. - Sistema básico de jerarquías. - Criterios de uso para componentes. - Reglas de adaptabilidad. - Orientaciones de accesibilidad. - Variaciones visuales documentadas. - Experiencias más predecibles para estudiantes y profesores. ### Riesgo que busca evitar Este pilar evita la proliferación de soluciones visuales atractivas pero inconsistentes, poco accesibles o difíciles de comprender y mantener. ## 6.7. Pilar 5: Arquitectura técnica y de componentes ### Propósito La arquitectura técnica y de componentes organiza las implementaciones que permiten materializar los patrones dentro de Moodle. Incluye componentes, código, configuraciones, integraciones, scripts y restricciones de funcionamiento. Su finalidad es ofrecer soluciones estables y reutilizables sin convertir CAPS en un repositorio exclusivamente técnico. ### Pregunta central **¿Cómo materializamos los patrones de manera segura, compatible, mantenible y reutilizable dentro de Moodle?** ### Capacidades que comprende - Clasificar componentes según su propósito. - Relacionar componentes con patrones. - Documentar dependencias técnicas. - Identificar compatibilidad con Moodle. - Controlar el uso de HTML, estilos y scripts. - Definir alternativas cuando una solución no sea compatible. - Evitar duplicaciones de código. - Establecer criterios mínimos de mantenimiento. - Reconocer componentes vigentes, experimentales y retirados. - Probar el comportamiento en distintos dispositivos. - Documentar restricciones de seguridad y funcionamiento. - Facilitar la sustitución de implementaciones sin perder el patrón. ### Resultados esperados - Catálogo de componentes reutilizables. - Implementaciones vinculadas a patrones. - Documentación de compatibilidad. - Versiones controladas. - Instrucciones mínimas de uso. - Pruebas y criterios de aceptación. - Alternativas técnicas conocidas. - Reducción de soluciones improvisadas. ### Riesgo que busca evitar Este pilar evita que el código se convierta en conocimiento aislado, que diferentes personas creen versiones incompatibles del mismo componente o que soluciones rápidas generen complejidad futura. ## 6.8. Pilar 6: Arquitectura de automatización e inteligencia artificial ### Propósito Este pilar organiza el uso de automatizaciones e inteligencia artificial para reducir trabajo repetitivo y ampliar la capacidad del área. La IA no constituye el núcleo de CAPS. Opera sobre los patrones, criterios, plantillas y componentes definidos por los demás pilares. Su finalidad es acelerar tareas conocidas, facilitar adaptaciones y asistir a las personas sin reemplazar la validación profesional. ### Pregunta central **¿Qué actividades pueden ser asistidas o automatizadas sin delegar a la herramienta las decisiones que definen la calidad y coherencia del sistema?** ### Capacidades que comprende - Identificar tareas repetitivas susceptibles de automatización. - Diseñar prompts vinculados con patrones concretos. - Proporcionar contexto institucional a las herramientas. - Generar implementaciones a partir de plantillas aprobadas. - Adaptar contenidos a formatos establecidos. - Comprobar estructuras y criterios básicos. - Generar variaciones controladas. - Documentar límites y riesgos. - Mantener revisión humana. - Evaluar la calidad de las salidas. - Convertir usos exitosos en flujos reutilizables. - Evitar la multiplicación descontrolada de código o estilos. ### Resultados esperados - Biblioteca de prompts validados. - Flujos asistidos para tareas recurrentes. - Entradas y salidas estandarizadas. - Criterios de revisión humana. - Registro de herramientas y usos permitidos. - Evidencia de ahorro de tiempo. - Reducción de variabilidad en resultados generados. - Automatizaciones sostenibles y comprensibles. ### Riesgo que busca evitar Este pilar evita que la IA se utilice como una fuente independiente de estándares o como una solución automática para problemas que el área aún no ha comprendido. ## 6.9. Capacidad transversal: Gobernanza y evolución ### Propósito La gobernanza permite que los seis pilares evolucionen sin perder coherencia. No debe entenderse como una estructura burocrática ni como un mecanismo de aprobación centralizada para cada decisión. Su función es establecer reglas mínimas para mantener la calidad, la vigencia y la integridad conceptual de CAPS. ### Pregunta central **¿Cómo permitimos que CAPS cambie, incorpore innovación y reciba contribuciones sin fragmentarse?** ### Capacidades que comprende - Establecer estados para los activos. - Definir criterios mínimos de validación. - Registrar versiones y cambios relevantes. - Identificar responsables de mantenimiento. - Resolver contradicciones entre patrones. - Retirar activos obsoletos. - Incorporar contribuciones de diferentes perfiles. - Distinguir experimentación de estándar institucional. - Revisar decisiones cuando cambien las condiciones. - Mantener trazabilidad sin producir documentación excesiva. ### Estados iniciales sugeridos **Candidato:** solución identificada que todavía requiere documentación o prueba. **En prueba:** activo que se está utilizando en uno o varios casos controlados. **Validado:** activo aprobado para reutilización regular. **Retirado:** activo que no debe utilizarse en nuevos proyectos, pero se conserva como referencia histórica. Esta clasificación permite experimentar sin convertir cada propuesta en un estándar inmediato. ### Riesgo que busca evitar La gobernanza evita dos extremos: - Un sistema completamente abierto en el que cada contribución crea una nueva regla. - Un sistema excesivamente controlado en el que innovar resulta lento o difícil. ## 6.10. Relación entre los pilares Los pilares deben operar como una cadena de capacidades conectadas. La **arquitectura pedagógica** establece el propósito de aprendizaje. La **arquitectura de experiencia y comunicación visual** determina cómo ese propósito se presenta y se hace comprensible. La **arquitectura técnica y de componentes** materializa la solución dentro de Moodle. La **arquitectura de producción** integra estas decisiones en el ciclo de construcción del curso. La **arquitectura de conocimiento** conserva y relaciona lo aprendido. La **arquitectura de automatización e inteligencia artificial** utiliza ese conocimiento para acelerar tareas y generar resultados controlados. La **gobernanza y evolución** mantiene coherencia entre todos los pilares y permite que el sistema mejore. La relación puede expresarse así: > **El propósito pedagógico orienta la experiencia; la experiencia define las necesidades de implementación; la producción integra las soluciones; el conocimiento conserva lo aprendido; y la automatización amplía la capacidad del sistema.** ## 6.11. Ejemplo integrado La necesidad de presentar lecturas y recursos complementarios puede recorrer los pilares de esta manera: ### Arquitectura pedagógica Define por qué se diferencian recursos obligatorios y complementarios, y qué debe comprender el estudiante. ### Arquitectura de experiencia y comunicación visual Establece la jerarquía de la información, la iconografía, el orden y la forma de acceso. ### Arquitectura técnica y de componentes Proporciona listas, tarjetas u otras implementaciones compatibles con Moodle. ### Arquitectura de producción Indica en qué momento se recibe, organiza, monta y valida la información bibliográfica. ### Arquitectura de conocimiento Documenta el patrón, sus variaciones, criterios y casos de uso. ### Arquitectura de automatización e inteligencia artificial Ayuda a estructurar referencias, seleccionar una plantilla o generar una implementación inicial basada en el patrón validado. ### Gobernanza y evolución Determina qué variación está aprobada, cuál se encuentra en prueba y qué mejoras deben incorporarse. Este ejemplo muestra que CAPS no organiza únicamente elementos técnicos. Organiza la relación completa entre necesidad, decisión, implementación y aprendizaje. ## 6.12. Criterios de suficiencia de la arquitectura La arquitectura será suficiente cuando permita responder con claridad: - Qué conocimiento debe conservar CAPS. - Cómo se conecta la intención pedagógica con el montaje. - Qué decisiones corresponden a experiencia visual. - Cómo se documentan las implementaciones técnicas. - Cómo se integra el conocimiento en la producción. - Qué tareas pueden automatizarse. - Cómo se incorporan mejoras sin fragmentar el sistema. No será necesario crear más pilares mientras estas capacidades permitan clasificar y comprender adecuadamente las necesidades del área. Si aparece una necesidad nueva, primero deberá evaluarse si puede incorporarse a un pilar existente. Crear nuevas categorías será una decisión excepcional, no una respuesta automática. ## 6.13. Síntesis de la arquitectura La arquitectura de CAPS se sostiene sobre seis pilares conectados: 1. **Conocimiento:** conserva y relaciona la experiencia. 2. **Producción:** organiza la transformación de solicitudes en cursos. 3. **Pedagogía:** mantiene el propósito de aprendizaje. 4. **Experiencia y comunicación visual:** facilita comprensión, navegación y accesibilidad. 5. **Técnica y componentes:** materializa soluciones sostenibles en Moodle. 6. **Automatización e inteligencia artificial:** amplía la capacidad mediante conocimiento validado. La gobernanza permite que todos ellos evolucionen como un sistema coherente. > **CAPS no separa la pedagogía, el diseño, la tecnología y la producción. Les proporciona una arquitectura común para que puedan trabajar como capacidades complementarias.** --- # 7. Modelo operativo mínimo de CAPS ## 7.1. Propósito del modelo operativo El modelo operativo describe cómo CAPS participa en la producción cotidiana de cursos. Su finalidad es conectar dos actividades que normalmente pueden ocurrir por separado: 1. La construcción de un curso que responde a una solicitud concreta. 2. La construcción de conocimiento reutilizable para futuros proyectos. CAPS debe evitar que la documentación se convierta en una actividad adicional desconectada del trabajo real. El conocimiento se captura mientras se resuelven necesidades concretas y únicamente cuando tiene valor para otros cursos. El modelo operativo se basa en un ciclo sencillo: > **Identificar, consultar, ensamblar, validar, aprender y evolucionar.** Este ciclo permite que cada proyecto utilice el conocimiento existente y, al mismo tiempo, contribuya a mejorarlo. ## 7.2. Principio operativo fundamental Cada solicitud de producción debe generar dos resultados. ### Resultado de producción Un curso o elemento de curso correctamente ensamblado, validado y entregado. ### Resultado de conocimiento Un aprendizaje, mejora, patrón, componente o caso de aplicación que pueda fortalecer CAPS. No todos los proyectos producirán un patrón nuevo. En muchos casos, el resultado de conocimiento consistirá en: - Confirmar que un patrón existente funciona. - Documentar una nueva variación. - Identificar una restricción. - Mejorar una plantilla. - Corregir un componente. - Actualizar un criterio. - Registrar un caso de aplicación. - Retirar una solución que ya no resulta adecuada. El objetivo es que la experiencia útil no desaparezca cuando termina el montaje. ## 7.3. Ciclo operativo de CAPS El ciclo operativo se compone de seis momentos: 1. Identificar la necesidad. 2. Consultar el conocimiento disponible. 3. Seleccionar y ensamblar la solución. 4. Validar el resultado. 5. Capturar el aprendizaje. 6. Evolucionar CAPS. Estos momentos no deben convertirse necesariamente en seis reuniones, formularios o aprobaciones. Pueden integrarse dentro del flujo normal de producción. ## 7.4. Momento 1: Identificar la necesidad ### Propósito Comprender qué problema debe resolverse antes de seleccionar un componente o comenzar el montaje. La necesidad debe describirse desde el propósito y no únicamente desde una solución solicitada. Por ejemplo: **Solicitud expresada como solución:** “Necesitamos un carrusel para las lecturas”. **Necesidad reformulada:** “Necesitamos presentar siete lecturas de manera organizada, diferenciando su prioridad y evitando que la sección resulte demasiado extensa”. La reformulación permite evaluar si un carrusel es realmente la alternativa adecuada o si existe un patrón más simple. ### Información mínima Para iniciar, debe ser posible reconocer: - Qué se necesita construir o modificar. - Para quién se construye. - Qué propósito pedagógico o comunicativo cumple. - Qué información estará disponible. - Qué restricciones existen. - Qué resultado espera la persona solicitante. - Si la necesidad ya ha aparecido en otros cursos. ### Resultado esperado Una descripción breve y comprensible del problema que debe resolverse. ### Pregunta de control **¿Comprendemos la necesidad o solamente estamos reaccionando a una solución propuesta?** ## 7.5. Momento 2: Consultar el conocimiento disponible ### Propósito Determinar si CAPS ya contiene conocimiento aplicable antes de diseñar una nueva solución. La consulta debe permitir encontrar: - Patrones relacionados. - Plantillas disponibles. - Componentes validados. - Variaciones existentes. - Decisiones arquitectónicas relevantes. - Casos de aplicación. - Restricciones o errores conocidos. - Prompts aprobados para apoyar la tarea. CAPS debe facilitar la consulta desde la necesidad, no exigir que la persona conozca de antemano el nombre técnico del componente. ### Posibles resultados de la consulta **Existe un patrón aplicable:** se revisan sus condiciones y se procede a utilizarlo. **Existe un patrón que requiere adaptación:** se documenta la variación necesaria y se verifica que conserve los criterios esenciales. **Existen componentes, pero no un patrón documentado:** la solución puede utilizarse de forma controlada y convertirse en candidata a patrón. **No existe conocimiento suficiente:** se inicia una solución experimental, procurando que el aprendizaje posterior pueda incorporarse a CAPS. ### Resultado esperado Una decisión explícita sobre si se reutilizará, adaptará o creará una solución. ### Pregunta de control **¿Estamos aprovechando conocimiento existente antes de construir algo nuevo?** ## 7.6. Momento 3: Seleccionar y ensamblar la solución ### Propósito Aplicar el patrón seleccionado utilizando las plantillas, componentes e implementaciones apropiadas para el contexto. El ensamblaje debe comenzar desde el patrón y sus criterios, no desde la personalización visual del componente. ### Actividades principales - Selección del patrón. - Elección de una plantilla. - Preparación de contenidos. - Selección de componentes. - Adaptación de información. - Configuración dentro de Moodle. - Incorporación de recursos visuales. - Aplicación de código autorizado. - Uso de prompts validados. - Verificación preliminar del funcionamiento. ### Tipos de adaptación **Adaptación de contenido:** modifica textos, recursos, referencias o información específica del curso. **Adaptación visual permitida:** ajusta imágenes, textos, cantidades o elementos variables dentro de límites definidos. **Adaptación estructural:** modifica la organización de una plantilla para responder a una situación particular. **Adaptación técnica:** cambia la implementación debido a restricciones de Moodle, compatibilidad o accesibilidad. Las adaptaciones estructurales o técnicas requieren mayor atención porque pueden alterar el comportamiento del patrón. ### Resultado esperado Una implementación funcional y suficientemente completa para ser revisada. ### Pregunta de control **¿La implementación conserva el propósito y los criterios del patrón seleccionado?** ## 7.7. Momento 4: Validar el resultado ### Propósito Comprobar que la solución funciona, es comprensible y responde a la necesidad original. La validación no debe limitarse a revisar si el código se ejecuta. Debe considerar las dimensiones relevantes del patrón. ### Niveles de validación **Validación funcional:** comprueba que enlaces, botones, scripts, recursos e interacciones funcionen correctamente. **Validación de información:** comprueba que los contenidos estén completos, organizados y correctamente identificados. **Validación pedagógica:** comprueba que la solución apoye el propósito de aprendizaje y no introduzca confusión. **Validación visual:** comprueba jerarquía, legibilidad, consistencia y comportamiento en diferentes pantallas. **Validación de accesibilidad:** comprueba que el contenido pueda ser percibido, comprendido y utilizado por diferentes personas. **Validación de mantenimiento:** comprueba que la solución pueda actualizarse sin depender de procedimientos excesivamente complejos. No todos los activos requieren el mismo nivel de validación. La profundidad dependerá del riesgo, el impacto y la novedad de la solución. ### Validación proporcional al riesgo **Riesgo bajo:** cambios de texto, fechas, imágenes o información dentro de una plantilla validada. Puede requerir una revisión breve. **Riesgo medio:** adaptaciones estructurales, nuevas variaciones o integración de herramientas conocidas. Requiere revisión funcional y de criterios. **Riesgo alto:** scripts nuevos, integraciones externas, cambios que afecten navegación, datos, accesibilidad o múltiples cursos. Requiere una validación técnica y conceptual más rigurosa. ### Resultado esperado Una solución: - Aprobada para publicación. - Aprobada con ajustes menores. - Devuelta para corrección. - Mantenida como experimento. - Rechazada por no cumplir los criterios. ### Pregunta de control **¿La solución solamente funciona o también resulta adecuada, comprensible y sostenible?** ## 7.8. Momento 5: Capturar el aprendizaje ### Propósito Identificar qué conocimiento generado durante el proyecto merece conservarse. La captura debe ser breve y enfocada. No se pretende documentar cada acción realizada, sino aquello que podría evitar trabajo futuro, mejorar una decisión o prevenir un error. ### Preguntas de aprendizaje - ¿El patrón resolvió adecuadamente la necesidad? - ¿Fue necesario adaptarlo? - ¿Apareció una variación recurrente? - ¿Se encontró una limitación? - ¿El componente produjo errores? - ¿Existió una solución más simple? - ¿La IA generó resultados útiles? - ¿Qué parte requirió más tiempo? - ¿Qué podría automatizarse? - ¿Qué información habría sido útil conocer antes? - ¿Esta experiencia puede ayudar a otro proyecto? ### Posibles resultados El aprendizaje puede convertirse en: - Una actualización del patrón. - Una nueva variación. - Un caso de aplicación. - Una lección aprendida. - Una mejora técnica. - Un criterio adicional. - Una modificación del prompt. - Una nueva plantilla. - Un activo candidato. - Una recomendación de retiro. ### Regla de captura mínima Un aprendizaje debería incorporarse cuando cumpla al menos una de estas condiciones: - Puede evitar un error futuro. - Puede reducir trabajo repetitivo. - Puede mejorar la calidad. - Puede facilitar la reutilización. - Puede aclarar una decisión. - Puede afectar varios cursos. - Puede orientar una automatización. - Puede modificar un estándar existente. ### Resultado esperado Un registro breve, relacionado con el activo correspondiente y suficientemente claro para ser evaluado. ### Pregunta de control **¿Qué debería saber el siguiente equipo antes de resolver una necesidad similar?** ## 7.9. Momento 6: Evolucionar CAPS ### Propósito Incorporar el aprendizaje al sistema de manera controlada. No todo aprendizaje debe modificar inmediatamente un patrón validado. CAPS debe distinguir entre una observación inicial y una mejora suficientemente probada. ### Acciones posibles **Confirmar:** la experiencia respalda el patrón actual y no requiere cambios. **Corregir:** se modifica un error, dato, instrucción o implementación sin alterar el patrón esencial. **Mejorar:** se actualizan criterios, documentación, ejemplos o componentes. **Crear una variación:** se documenta una forma recurrente de aplicar el mismo patrón en otro contexto. **Crear un activo candidato:** se registra una nueva solución que necesita pruebas antes de convertirse en estándar. **Reemplazar una implementación:** se conserva el patrón, pero se cambia el componente o tecnología utilizada. **Retirar:** se evita el uso futuro de una solución que resulte obsoleta, riesgosa o innecesariamente compleja. ### Resultado esperado CAPS actualizado de forma trazable, sin convertir cada caso particular en una nueva regla institucional. ### Pregunta de control **¿El aprendizaje es suficientemente general y probado para modificar el sistema?** ## 7.10. Dos rutas operativas Para mantener simplicidad, CAPS puede operar inicialmente mediante dos rutas. ### Ruta A: Aplicación de un patrón existente Se utiliza cuando la necesidad ya cuenta con una solución validada. El recorrido es: 1. Identificar la necesidad. 2. Consultar CAPS. 3. Seleccionar el patrón. 4. Aplicar una plantilla o componente validado. 5. Adaptar el contenido. 6. Revisar el resultado. 7. Publicar. 8. Registrar únicamente aprendizajes relevantes. Esta ruta debe ser rápida y representar la mayoría de los casos cuando CAPS madure. ### Ruta B: Desarrollo o evolución de un patrón Se utiliza cuando: - No existe una solución. - El patrón actual no cubre la necesidad. - Se requiere una variación relevante. - Aparece una nueva tecnología. - Se identifica un problema recurrente. - Una solución experimental ofrece valor. El recorrido es: 1. Describir la necesidad. 2. Revisar soluciones relacionadas. 3. Crear una propuesta inicial. 4. Aplicarla en un caso controlado. 5. Validar resultados y riesgos. 6. Documentar la solución. 7. Clasificarla como candidata o en prueba. 8. Repetir la aplicación cuando sea necesario. 9. Validarla o retirarla. La existencia de estas dos rutas evita tratar cada curso como un experimento y, al mismo tiempo, permite innovar cuando el conocimiento disponible no resulta suficiente. ## 7.11. Estados operativos de los activos CAPS manejará inicialmente cuatro estados. ### Candidato Es una solución identificada que podría aportar valor, pero aún no cuenta con documentación o evidencia suficiente. Puede originarse en: - Una propuesta de una persona. - Un componente existente. - Una solución generada con IA. - Un hallazgo en un proyecto. - Una necesidad nueva. ### En prueba Es un activo que se está aplicando de manera controlada para evaluar su utilidad, claridad, compatibilidad y sostenibilidad. Debe indicar: - Qué se está probando. - En qué cursos. - Qué aspectos se observarán. - Qué riesgos existen. - Qué resultado determinará su continuidad. ### Validado Es un activo aprobado para su utilización regular dentro de las condiciones documentadas. La validación no significa que el activo sea permanente. Puede actualizarse, reemplazarse o retirarse. ### Retirado Es un activo que no debe utilizarse en nuevos proyectos. Se conserva como referencia para: - Comprender cursos anteriores. - Explicar decisiones históricas. - Facilitar migraciones. - Evitar que se repitan errores. ## 7.12. Niveles de cambio No todas las modificaciones requieren el mismo tratamiento. CAPS puede distinguir tres niveles. ### Cambio local Afecta una implementación dentro de un curso específico. Ejemplos: - Cambiar una imagen. - Ajustar un texto. - Corregir un enlace. - Modificar una fecha. No requiere modificar el patrón. ### Cambio de activo Afecta un componente, plantilla, prompt o criterio reutilizable. Ejemplos: - Corregir una estructura HTML. - Mejorar la adaptabilidad de una tarjeta. - Actualizar un prompt. - Agregar una variación. Requiere actualizar el activo y comprobar que no afecte sus usos principales. ### Cambio arquitectónico Afecta varios patrones o modifica una regla transversal. Ejemplos: - Cambiar la estructura general de navegación. - Adoptar un nuevo sistema de componentes. - Prohibir una tecnología. - Modificar criterios institucionales de accesibilidad. - Incorporar una nueva plataforma de automatización. Requiere documentar la decisión y revisar sus consecuencias en el sistema. Esta clasificación permite concentrar la revisión en cambios de mayor impacto. ## 7.13. Información mínima de una necesidad Para no aumentar la carga administrativa, una solicitud relacionada con CAPS debería responder inicialmente cinco preguntas: 1. ¿Qué se necesita? 2. ¿Qué propósito cumple? 3. ¿Quién utilizará el resultado? 4. ¿Qué información o recursos están disponibles? 5. ¿Qué restricciones o condiciones especiales existen? Esta información puede formar parte de la solicitud normal de producción. No necesita convertirse en un documento separado. ## 7.14. Información mínima de un patrón Un patrón candidato puede comenzar con una ficha breve: - Nombre. - Problema que resuelve. - Contexto de uso. - Resultado esperado. - Criterios principales. - Componentes o implementaciones relacionadas. - Riesgos o limitaciones. - Estado. - Caso en el que se está probando. - Responsable temporal de su seguimiento. La documentación puede ampliarse conforme el patrón gane madurez. No debe exigirse una ficha extensa antes de comprobar que la solución tiene valor. ## 7.15. Información mínima de una implementación Una implementación reutilizable debe indicar: - Patrón al que pertenece. - Tecnología utilizada. - Instrucciones básicas. - Elementos que pueden modificarse. - Elementos que deben conservarse. - Dependencias. - Restricciones conocidas. - Estado de validación. - Ejemplo funcional. - Versión o fecha de actualización. Esta información permite que una persona utilice el componente sin depender únicamente de quien lo creó. ## 7.16. Incorporación de inteligencia artificial al ciclo La IA puede apoyar distintos momentos del modelo operativo. ### Durante la identificación Puede ayudar a organizar la solicitud, detectar información faltante o reformular una necesidad. ### Durante la consulta Puede facilitar la búsqueda de patrones y componentes relacionados. ### Durante el ensamblaje Puede generar borradores, adaptar contenidos, producir código basado en plantillas o estructurar información. ### Durante la validación Puede apoyar comprobaciones básicas, detectar inconsistencias o comparar la implementación con criterios documentados. ### Durante la captura del aprendizaje Puede resumir hallazgos y proponer actualizaciones para revisión humana. ### Durante la evolución Puede identificar patrones repetidos en varios casos o sugerir activos que requieren actualización. En todos los momentos, la IA opera como asistente. Las decisiones sobre pertinencia, calidad, validación y estandarización permanecen bajo responsabilidad humana. ## 7.17. Indicadores operativos iniciales CAPS debe demostrar que mejora la capacidad del área. Sin embargo, al comienzo se recomienda utilizar pocos indicadores. ### Reutilización Porcentaje de necesidades que utilizaron un patrón, plantilla o componente existente. ### Tiempo de montaje Tiempo requerido para montar elementos recurrentes antes y después de disponer de activos validados. ### Retrabajo Cantidad de correcciones originadas en inconsistencias, errores técnicos o falta de criterios claros. ### Adopción Cantidad de cursos, personas o proyectos que utilizan activos de CAPS. ### Aprendizaje incorporado Cantidad de patrones, variaciones o activos mejorados a partir de proyectos reales. ### Estabilidad Frecuencia con la que un activo validado necesita correcciones posteriores por problemas previsibles. Los indicadores deben apoyar decisiones. No deben convertirse en una carga de reporte mayor que el beneficio obtenido. ## 7.18. Criterios de eficiencia del modelo El modelo operativo será eficiente cuando: - Las personas puedan localizar una solución sin depender de preguntas informales. - Los patrones frecuentes puedan aplicarse con pocos pasos. - Las revisiones se concentren en cambios de mayor riesgo. - La documentación se produzca dentro del trabajo normal. - Los aprendizajes relevantes regresen al sistema. - Las nuevas personas puedan utilizar activos sin conocer toda su historia. - La IA pueda trabajar con instrucciones y límites claros. - CAPS reduzca decisiones repetitivas. - La innovación pueda probarse sin convertirse inmediatamente en estándar. ## 7.19. Riesgos del modelo operativo ### Documentar demasiado CAPS puede perder adopción si cada acción exige completar fichas extensas. **Respuesta:** aplicar documentación progresiva y proporcional a la madurez del activo. ### Documentar demasiado poco Los activos pueden convertirse nuevamente en fragmentos sin contexto. **Respuesta:** exigir siempre propósito, condiciones de uso y relación con un patrón. ### Convertir cada excepción en una variación El catálogo puede crecer sin control. **Respuesta:** crear variaciones solamente cuando la necesidad sea recurrente. ### Validar todo de la misma manera El sistema puede volverse lento. **Respuesta:** utilizar revisión proporcional al riesgo. ### Utilizar activos sin consultar sus condiciones La reutilización puede convertirse en copia automática. **Respuesta:** presentar el propósito y las restricciones antes de la implementación. ### Automatizar antes de estabilizar La IA puede acelerar un proceso confuso y multiplicar sus errores. **Respuesta:** automatizar únicamente tareas suficientemente comprendidas. ## 7.20. Síntesis del modelo operativo El modelo operativo de CAPS puede expresarse de la siguiente forma: > **Cada necesidad consulta el conocimiento existente, cada solución aplica o amplía un patrón, cada implementación se valida y cada aprendizaje relevante regresa al sistema.** El ciclo mínimo es: **Necesidad → consulta → ensamblaje → validación → aprendizaje → evolución.** Este modelo conecta la producción de cursos con la construcción de capacidad institucional. CAPS no añade un proceso paralelo al montaje. Convierte el montaje cotidiano en la principal fuente de conocimiento para mejorar el sistema. --- # 8. Modelo organizacional y de responsabilidades de CAPS ## 8.1. Propósito del modelo organizacional CAPS requiere participación de distintos perfiles para integrar conocimiento pedagógico, visual, técnico y operativo. Sin embargo, permitir múltiples contribuciones sin responsabilidades claras puede aumentar la coordinación, generar decisiones contradictorias y debilitar la integridad conceptual. El modelo organizacional de CAPS busca responder cinco preguntas: 1. ¿Quién orienta estratégicamente el framework? 2. ¿Quién protege su coherencia? 3. ¿Quién puede proponer y construir activos? 4. ¿Quién valida las soluciones? 5. ¿Quién mantiene actualizado el conocimiento? El modelo debe ser suficientemente claro para evitar dependencias personales, pero suficientemente liviano para no crear una estructura burocrática paralela al trabajo del área. Su principio organizacional es: > **CAPS distribuye la contribución, pero hace explícita la responsabilidad sobre la coherencia y las decisiones.** ## 8.2. Roles como funciones, no necesariamente como cargos Los roles de CAPS representan responsabilidades dentro del sistema. Una misma persona puede desempeñar varios roles, especialmente durante las primeras etapas. Del mismo modo, un rol puede ser compartido por varias personas cuando el volumen de trabajo aumente. Por ejemplo: - Un diseñador instruccional puede actuar como contribuidor y revisor pedagógico. - Un diseñador gráfico puede contribuir patrones visuales y validar componentes de experiencia. - Un perfil técnico puede construir implementaciones y revisar compatibilidad. - Un coordinador puede asumir la orientación estratégica. - Una persona con visión transversal puede actuar como responsable de arquitectura de CAPS. Esta flexibilidad permite iniciar sin modificar inmediatamente la estructura formal del área. ## 8.3. Estructura mínima de responsabilidades CAPS necesita inicialmente cinco funciones principales: 1. Orientación estratégica. 2. Arquitectura e integridad conceptual. 3. Contribución especializada. 4. Validación. 5. Curaduría y mantenimiento. La implementación cotidiana de los patrones forma parte del proceso normal de producción y no requiere crear un órgano separado. ## 8.4. Función 1: Orientación estratégica ### Propósito Asegurar que CAPS responda a las prioridades, necesidades y capacidades institucionales. Esta función conecta el framework con: - La estrategia del área. - Las necesidades de producción. - El crecimiento de solicitudes. - La calidad esperada. - Las políticas institucionales. - La disponibilidad de recursos. - La evolución de Moodle y de las tecnologías utilizadas. ### Responsabilidades La orientación estratégica debe: - Definir los objetivos generales de CAPS. - Priorizar las capacidades que se desarrollarán. - Asegurar respaldo institucional. - Resolver decisiones que superen el alcance operativo. - Facilitar la colaboración entre áreas. - Revisar los resultados generales del framework. - Evitar que CAPS se convierta exclusivamente en una iniciativa técnica. - Confirmar que la inversión de esfuerzo produzca valor verificable. ### Decisiones que le corresponden - Alcance institucional del framework. - Prioridades generales. - Recursos necesarios. - Relación con otras iniciativas. - Cambios que afecten políticas o responsabilidades organizacionales. - Continuidad o ampliación del proyecto. ### Perfil sugerido Esta función debería ser asumida por la jefatura o coordinación responsable de la producción de cursos, con apoyo de quienes tengan capacidad de decisión sobre procesos y recursos. ### Pregunta rectora **¿CAPS está fortaleciendo una capacidad prioritaria para el área y la institución?** ## 8.5. Función 2: Arquitectura e integridad conceptual ### Propósito Conservar una visión coherente del framework mientras diferentes personas y disciplinas realizan aportes. Esta función representa la voz arquitectónica común de CAPS. No debe controlar cada modificación menor, pero sí intervenir cuando una decisión pueda afectar varios patrones, cursos o pilares. Puede denominarse: - **CAPS Architect** - **Pattern System Architect** - **Responsable de arquitectura de CAPS** No es necesario crear de inmediato un nuevo cargo formal. Lo importante es asignar explícitamente esta responsabilidad. ### Responsabilidades La función de arquitectura debe: - Mantener el marco conceptual. - Proteger los principios arquitectónicos. - Revisar decisiones transversales. - Detectar contradicciones y duplicaciones. - Relacionar patrones entre diferentes disciplinas. - Asegurar que los componentes respondan a necesidades documentadas. - Diferenciar innovaciones útiles de variaciones innecesarias. - Orientar la evolución del catálogo. - Facilitar acuerdos entre perfiles. - Mantener la integridad conceptual planteada por Brooks. - Evitar que herramientas o tecnologías específicas definan por sí solas el sistema. ### Decisiones que le corresponden - Creación de nuevas categorías de patrones. - Cambios al vocabulario del framework. - Modificaciones de principios arquitectónicos. - Aprobación de decisiones transversales. - Resolución de conflictos entre patrones. - Definición de relaciones entre pilares. - Determinación de cuándo una propuesta requiere un patrón nuevo. - Revisión de cambios de alto impacto. ### Límites de la función El responsable de arquitectura no debe: - Aprobar cada cambio de texto o contenido. - Sustituir el criterio de los especialistas. - Centralizar toda la producción. - Diseñar personalmente todos los patrones. - Convertirse en un cuello de botella. - Impedir la experimentación controlada. Su función consiste en proteger la coherencia, no en ejecutar o controlar todo el trabajo. ### Pregunta rectora **¿Las distintas contribuciones continúan formando parte de un mismo sistema comprensible?** ## 8.6. Función 3: Contribución especializada ### Propósito Incorporar al framework el conocimiento de las personas que participan directamente en la producción y conocen los problemas reales. Cualquier integrante autorizado puede actuar como contribuidor cuando: - Identifica una necesidad recurrente. - Propone un patrón. - Crea o mejora un componente. - Documenta una lección. - Registra un caso de aplicación. - Mejora una plantilla. - Propone un prompt. - Detecta una restricción. - Sugiere retirar un activo. ### Tipos de contribución **Contribución pedagógica:** intención de aprendizaje, organización de contenidos, claridad de instrucciones, secuencias, actividades y evaluación. **Contribución visual y de experiencia:** jerarquía visual, navegación, legibilidad, accesibilidad, adaptabilidad, identidad institucional y uso de componentes gráficos. **Contribución técnica:** Moodle, HTML y estilos, scripts, integraciones, compatibilidad, seguridad, mantenimiento y restricciones de plataforma. **Contribución operativa:** flujo de montaje, información necesaria, tiempos, retrabajos, dependencias, problemas recurrentes y oportunidades de reutilización. **Contribución de automatización e IA:** prompts, automatizaciones, tareas repetitivas, estructuración de entradas, evaluación de resultados y controles humanos. ### Responsabilidades Quien contribuye debe: - Describir el problema antes de presentar la solución. - Relacionar la propuesta con un patrón existente cuando sea posible. - Explicar condiciones y limitaciones. - Presentar evidencia o un caso de prueba. - Responder observaciones durante la validación. - Incorporar ajustes acordados. - Evitar convertir preferencias personales en reglas generales. ### Pregunta rectora **¿Qué conocimiento de mi especialidad puede ayudar a resolver esta necesidad de forma reutilizable?** ## 8.7. Función 4: Validación ### Propósito Comprobar que los activos y sus implementaciones resulten pertinentes, funcionales y sostenibles. La validación debe realizarse según la naturaleza y el riesgo de la propuesta. No todas las soluciones necesitan ser revisadas por todas las disciplinas. ### Validación distribuida - Los aspectos pedagógicos son revisados por un perfil con competencia pedagógica. - Los aspectos visuales y de experiencia son revisados por un perfil de diseño. - Los aspectos técnicos son revisados por un perfil con conocimiento de Moodle y desarrollo. - Los cambios arquitectónicos son revisados por el responsable de arquitectura. - Las decisiones estratégicas son revisadas por quien orienta el framework. Esta distribución evita que una sola persona deba dominar todas las dimensiones. ### Responsabilidades La función de validación debe: - Aplicar criterios previamente definidos. - Concentrarse en la dimensión de su competencia. - Diferenciar problemas críticos de recomendaciones. - Registrar observaciones comprensibles. - Evitar revisiones basadas exclusivamente en gustos personales. - Confirmar que las correcciones fueron aplicadas. - Recomendar el estado del activo. - Identificar riesgos que requieran revisión adicional. ### Tipos de decisión Un revisor puede recomendar: - Aprobar. - Aprobar con ajustes menores. - Mantener en prueba. - Devolver para corrección. - Solicitar una validación especializada. - Rechazar la propuesta. - Recomendar el retiro de un activo existente. ### Pregunta rectora **¿La solución cumple los criterios necesarios para utilizarse en el contexto propuesto?** ## 8.8. Función 5: Curaduría y mantenimiento ### Propósito Mantener el catálogo de CAPS organizado, actualizado y comprensible. La curaduría no consiste solamente en almacenar archivos. Debe asegurar que los activos: - Puedan localizarse. - Tengan un estado visible. - Estén relacionados con sus patrones. - Conserven información básica. - No se encuentren duplicados. - Indiquen cuándo fueron actualizados. - Muestren restricciones conocidas. - Señalen qué versiones siguen vigentes. ### Responsabilidades La función de curaduría debe: - Revisar que las fichas contengan la información mínima. - Organizar los activos en el catálogo. - Mantener nombres y etiquetas consistentes. - Relacionar patrones, componentes y casos. - Registrar versiones relevantes. - Cambiar el estado de los activos cuando corresponda. - Identificar documentación incompleta. - Detectar duplicaciones. - Mantener visibles los activos retirados sin promover su reutilización. - Apoyar búsquedas y recuperación del conocimiento. - Preparar revisiones periódicas del catálogo. ### Perfil sugerido Puede ser asumida por una persona con capacidades de: - Gestión del conocimiento. - Documentación. - Organización de información. - Administración de repositorios. - Coordinación de producción. No requiere que la persona sea experta en todas las disciplinas, pero sí que pueda reconocer cuándo debe solicitar apoyo especializado. ### Pregunta rectora **¿El conocimiento se encuentra suficientemente organizado para que otras personas puedan encontrarlo y utilizarlo?** ## 8.9. Función de aplicación y ensamblaje ### Propósito Utilizar los patrones, plantillas y componentes de CAPS dentro de proyectos reales. Aunque no forma parte del núcleo de gobierno, esta función es fundamental porque conecta el framework con la operación cotidiana. La realizan diseñadores, montadores, productores y otros perfiles que construyen cursos. ### Responsabilidades Quien aplica un patrón debe: - Consultar el conocimiento disponible. - Seleccionar una solución adecuada. - Respetar los criterios esenciales. - Adaptar únicamente los elementos permitidos. - Validar el resultado. - Registrar problemas o aprendizajes relevantes. - Evitar modificaciones estructurales no documentadas. - Informar cuando un activo no responda adecuadamente a la necesidad. ### Pregunta rectora **¿Estoy aplicando el patrón de acuerdo con su propósito y devolviendo al sistema el aprendizaje relevante?** ## 8.10. Función de asesoría especializada ### Propósito Aportar conocimiento externo o altamente especializado cuando CAPS enfrente decisiones que superen las capacidades disponibles dentro del área. Esta función puede ser temporal y activarse según la necesidad. ### Ámbitos posibles de asesoría - Arquitectura empresarial. - Gestión del conocimiento. - Diseño de sistemas de patrones. - Arquitectura de información. - Accesibilidad digital. - Experiencia de usuario. - Moodle y tecnologías educativas. - Automatización e inteligencia artificial. - Medición y mejora de procesos. - Gestión del cambio. ### Perfil idóneo Para acompañar la construcción inicial de CAPS, el perfil más adecuado sería un profesional con experiencia combinada en: - Arquitectura organizacional o empresarial. - Gestión del conocimiento. - Diseño de servicios o procesos. - Producción de aprendizaje digital. - Facilitación interdisciplinaria. - Traducción de conceptos estratégicos a modelos operativos. La asesoría técnica de software será importante para el catálogo de componentes y las automatizaciones, pero no debería dirigir por sí sola la arquitectura general del framework. ### Pregunta rectora **¿Esta decisión requiere conocimiento especializado que el equipo no posee actualmente?** ## 8.11. Derechos de decisión Para evitar ambigüedad, CAPS distingue entre proponer, revisar y decidir. ### Proponer Cualquier contribuidor autorizado puede presentar: - Un nuevo patrón. - Una variación. - Un componente. - Una mejora. - Una automatización. - Una lección aprendida. - Un retiro. ### Revisar La propuesta es revisada por los perfiles cuya especialidad resulte afectada. No es necesario involucrar a todas las personas en cada revisión. ### Decidir La decisión depende del nivel del cambio: - **Cambio local:** responsable del montaje o de la entrega, siempre que no modifique un activo compartido. - **Cambio de activo:** revisión especializada y actualización por curaduría. - **Cambio arquitectónico:** función de arquitectura, con consulta a especialistas. - **Cambio estratégico:** orientación estratégica, con recomendación de arquitectura. Esta estructura evita tanto la centralización excesiva como la ausencia de responsabilidad. ## 8.12. Matriz mínima de responsabilidades | Actividad | Propone | Revisa | Decide | Registra | |---|---|---|---|---| | Aplicar un patrón validado | Montador o productor | Revisión habitual del curso | Responsable de entrega | Solo si existe aprendizaje | | Crear un patrón candidato | Cualquier contribuidor | Especialistas relacionados | Arquitectura CAPS | Curaduría | | Validar un patrón | Contribuidor o arquitectura | Revisores especializados | Arquitectura CAPS | Curaduría | | Modificar un componente | Perfil técnico o diseñador | Especialista correspondiente | Responsable del activo | Curaduría | | Crear una variación | Contribuidor | Especialistas relacionados | Arquitectura o responsable delegado | Curaduría | | Aprobar un prompt | Especialista en IA o contribuidor | Especialista del patrón y usuario responsable | Responsable del activo | Curaduría | | Retirar un activo | Cualquier usuario puede recomendarlo | Especialistas afectados | Arquitectura CAPS | Curaduría | | Cambiar un principio | Arquitectura o dirección | Representantes de los pilares | Orientación estratégica | Curaduría | | Priorizar capacidades | Arquitectura y equipo | Áreas involucradas | Orientación estratégica | Responsable de CAPS | La matriz debe utilizarse como referencia, no como un trámite obligatorio para cada actividad cotidiana. ## 8.13. Núcleo mínimo de CAPS Durante la etapa inicial, CAPS puede operar con un núcleo pequeño de tres funciones: ### Responsable estratégico Asegura alineación institucional y elimina obstáculos. ### Responsable de arquitectura y curaduría Protege la integridad conceptual, organiza el catálogo y coordina la evolución. ### Red de contribuidores y revisores Aporta y valida conocimiento pedagógico, visual, técnico y operativo según cada necesidad. Este núcleo permite iniciar sin constituir un comité permanente ni crear múltiples cargos. A medida que aumenten el catálogo, el número de cursos y el uso del framework, arquitectura y curaduría podrían separarse en funciones distintas. ## 8.14. Mecanismos mínimos de coordinación CAPS necesita pocos espacios de coordinación, cada uno con un propósito claro. ### Revisión de activos candidatos Espacio breve para analizar propuestas que podrían convertirse en patrones o componentes compartidos. Debe concentrarse en: - El problema. - La recurrencia. - La utilidad. - Los riesgos. - La prueba necesaria. No debe utilizarse para revisar cambios menores de cada curso. ### Revisión periódica del catálogo Permite identificar: - Activos sin uso. - Duplicaciones. - Elementos obsoletos. - Patrones que requieren actualización. - Soluciones experimentales que pueden validarse. - Necesidades recurrentes todavía no atendidas. ### Revisión estratégica Analiza si CAPS está: - Reduciendo tiempos. - Aumentando reutilización. - Disminuyendo retrabajos. - Facilitando colaboración. - Apoyando la capacidad del área. - Respondiendo a nuevas necesidades. La frecuencia de estos espacios debe ajustarse al volumen real. No es necesario establecer reuniones frecuentes mientras exista poca actividad. ## 8.15. Interfaces de colaboración Una interfaz de colaboración define qué información necesita una persona para recibir, desarrollar o revisar un trabajo. ### Entre pedagogía y producción Debe estar claro: - Qué propósito tiene la sección. - Qué debe hacer o comprender el estudiante. - Qué información es obligatoria. - Qué elementos pueden adaptarse. ### Entre diseño y montaje Debe estar claro: - Qué componente se utilizará. - Qué contenido debe contener. - Qué elementos visuales pueden variar. - Qué restricciones existen. ### Entre montaje y desarrollo técnico Debe estar claro: - Qué comportamiento se espera. - Qué plataforma o versión se utiliza. - Qué dependencias existen. - Qué riesgos deben controlarse. - Cómo se validará el resultado. ### Entre contribución y curaduría Debe estar claro: - Qué problema resuelve el activo. - Con qué patrón se relaciona. - Qué estado tiene. - Qué evidencia lo respalda. - Quién puede aclarar dudas. Estas interfaces reducen la necesidad de coordinación constante y permiten mayor autonomía. ## 8.16. Protección de la integridad conceptual La integridad conceptual requiere una voz común, pero no una sola persona que tome todas las decisiones. CAPS la protege mediante: - Principios explícitos. - Vocabulario compartido. - Patrones documentados. - Decisiones arquitectónicas registradas. - Revisión especializada. - Responsable de arquitectura. - Estados de madurez. - Criterios de validación. - Límites claros de adaptación. Este modelo refleja una idea central de Brooks: la coherencia de un sistema no emerge automáticamente de la cantidad de participantes. Debe ser diseñada y protegida. La responsabilidad arquitectónica permite integrar aportes sin convertir CAPS en una colección de soluciones independientes. ## 8.17. Evitar el “hombre-mes” organizacional La incorporación de más personas no aumenta automáticamente la capacidad de CAPS. Cada nuevo participante requiere: - Comprender el lenguaje. - Conocer los patrones. - Identificar los canales de decisión. - Aprender las herramientas. - Coordinarse con otras personas. Por ello, antes de ampliar el número de contribuidores, CAPS debe mejorar: - La claridad de sus fichas. - La facilidad de consulta. - Las plantillas de contribución. - Los criterios de validación. - La documentación de responsabilidades. - Los mecanismos de incorporación. La capacidad sostenible proviene de reducir el costo de coordinación, no solamente de aumentar el número de participantes. ## 8.18. Incorporación de nuevos participantes Toda persona que vaya a utilizar o contribuir a CAPS debería comprender inicialmente: 1. El propósito del framework. 2. La diferencia entre patrón y componente. 3. Los principios arquitectónicos. 4. Cómo consultar el catálogo. 5. Cómo aplicar un activo validado. 6. Cómo reportar un aprendizaje. 7. Qué cambios puede realizar directamente. 8. Qué cambios requieren revisión. La incorporación debe ser práctica y breve. Puede realizarse mediante: - Una guía inicial. - Un recorrido por patrones frecuentes. - Un caso de ejemplo. - Una actividad de aplicación. - Acompañamiento durante el primer uso. No es necesario enseñar toda la arquitectura antes de permitir que una persona utilice el sistema. ## 8.19. Responsabilidad sobre inteligencia artificial El uso de IA requiere responsabilidades explícitas. ### Quien diseña el prompt Debe relacionarlo con un patrón, establecer entradas, restricciones y resultados esperados. ### Quien utiliza la herramienta Debe proporcionar la información adecuada y revisar la salida. ### Quien valida el resultado Debe contar con competencia en la dimensión afectada: pedagógica, visual, técnica u operativa. ### Quien mantiene el activo Debe actualizar el prompt cuando cambien los patrones, las herramientas o las restricciones. La IA no puede asumir la responsabilidad sobre: - Pertinencia pedagógica. - Cumplimiento institucional. - Seguridad. - Accesibilidad. - Aprobación de estándares. - Publicación definitiva. ## 8.20. Criterios para evaluar el modelo organizacional El modelo funcionará adecuadamente cuando: - Las personas sepan qué pueden decidir. - Las contribuciones no dependan de una sola persona. - La arquitectura tenga un responsable visible. - Las revisiones sean proporcionales al riesgo. - Los especialistas participen únicamente cuando su conocimiento sea necesario. - El catálogo permanezca organizado y vigente. - La innovación pueda probarse con rapidez. - Los cambios transversales estén documentados. - La coordinación no requiera reuniones constantes. - La incorporación de nuevas personas resulte progresivamente más sencilla. ## 8.21. Riesgos organizacionales ### Centralización excesiva Una sola persona revisa todas las decisiones y se convierte en cuello de botella. **Respuesta:** delegar cambios locales y de activos de bajo riesgo, reservando la revisión arquitectónica para decisiones transversales. ### Ausencia de voz arquitectónica Cada disciplina crea sus propios estándares. **Respuesta:** asignar explícitamente la responsabilidad de integridad conceptual. ### Comités demasiado grandes Las decisiones simples requieren múltiples reuniones. **Respuesta:** involucrar únicamente los perfiles afectados y utilizar revisión proporcional al impacto. ### Roles ambiguos Nadie sabe quién decide, valida o actualiza. **Respuesta:** establecer derechos de decisión y responsables visibles para cada activo. ### Dependencia de expertos individuales El conocimiento no puede utilizarse sin consultar a sus autores. **Respuesta:** fortalecer fichas, ejemplos, criterios y transferencia. ### Curaduría sin conocimiento del trabajo real El catálogo se organiza formalmente, pero no refleja las necesidades de producción. **Respuesta:** conectar la curaduría con los proyectos y las lecciones aprendidas. ### Innovación sin integración Se crean nuevas soluciones, pero no se incorporan al framework. **Respuesta:** utilizar estados de candidato y en prueba, con una ruta clara hacia validación o retiro. ## 8.22. Síntesis del modelo organizacional CAPS requiere una organización ligera basada en responsabilidades, no necesariamente en nuevos cargos. Su estructura mínima comprende: - **Orientación estratégica**, para asegurar relevancia institucional. - **Arquitectura**, para proteger la integridad conceptual. - **Contribución especializada**, para incorporar conocimiento real. - **Validación distribuida**, para asegurar calidad. - **Curaduría**, para preservar y organizar los activos. - **Aplicación**, para conectar el framework con la producción cotidiana. El principio organizacional puede resumirse así: > **Muchas personas pueden contribuir a CAPS, pero las decisiones deben tener responsables claros, criterios compartidos y una arquitectura común.** El modelo busca que la colaboración aumente la capacidad del área sin multiplicar innecesariamente la coordinación, las reuniones o las aprobaciones. --- # 9. Modelo de activos y catálogo de CAPS ## 9.1. Propósito del catálogo El catálogo de CAPS es el espacio organizado en el que se conservan, relacionan y consultan los activos de conocimiento utilizados para la producción y el montaje de cursos. Su finalidad es permitir que una persona pueda: - Partir de una necesidad concreta. - Encontrar un patrón aplicable. - Comprender sus criterios de uso. - Identificar las plantillas y componentes disponibles. - Consultar implementaciones compatibles con Moodle. - Reconocer restricciones y riesgos. - Revisar casos anteriores. - Utilizar prompts o automatizaciones aprobadas. - Registrar aprendizajes derivados de una nueva aplicación. El catálogo no debe limitarse a mostrar qué recursos existen. Debe explicar **para qué sirven, cuándo deben utilizarse y cómo se relacionan con el sistema completo**. Su principio fundamental es: > **CAPS organiza el conocimiento desde la necesidad hacia la solución, no desde el archivo hacia un posible uso.** ## 9.2. El catálogo como red de conocimiento El catálogo no debe entenderse como una estructura lineal de carpetas. En una biblioteca tradicional, un archivo suele ubicarse en un único lugar. En CAPS, un mismo activo puede relacionarse con diferentes necesidades, patrones, cursos y disciplinas. Por ejemplo, un componente de tarjeta puede estar relacionado con: - El patrón de presentación de lecturas. - El patrón de presentación del profesor. - El patrón de introducción a una unidad. - Un criterio de jerarquía visual. - Una implementación específica en Moodle. - Diferentes casos de aplicación. Por esta razón, CAPS debe funcionar como una **red de activos relacionados**, aunque inicialmente se implemente mediante una herramienta sencilla como Notion, una wiki o un repositorio documental. La herramienta puede cambiar. La estructura conceptual debe conservarse. ## 9.3. Principios de organización del catálogo ### Organización por problemas y propósitos La entrada principal al catálogo debe ser la necesidad que una persona busca resolver. Algunos ejemplos: - Presentar lecturas y recursos. - Organizar una unidad. - Comunicar fechas. - Presentar al profesor. - Integrar contenido interactivo. - Orientar una actividad. - Facilitar la navegación. - Mostrar información extensa sin sobrecargar la página. ### Separación entre conocimiento e implementación Los patrones deben conservarse separados del código, las configuraciones o las herramientas específicas. Esto permite cambiar una implementación sin perder el conocimiento de la solución. ### Información progresiva La ficha inicial debe ser breve y útil. Los detalles técnicos, casos y decisiones pueden consultarse en niveles posteriores. La persona no debe leer toda la documentación para identificar si un patrón resulta pertinente. ### Relaciones explícitas Cada activo debe mostrar sus conexiones principales: - Qué patrón implementa. - Qué criterios cumple. - Qué otros activos requiere. - En qué casos se ha utilizado. - Qué versión se encuentra vigente. - Qué restricciones presenta. ### Estado visible Toda persona debe poder reconocer si un activo está: - Como candidato. - En prueba. - Validado. - Retirado. ### Responsabilidad identificable Cada activo compartido debe tener una persona o función responsable de revisar su vigencia y coordinar sus actualizaciones. ### Simplicidad taxonómica CAPS utilizará pocas categorías estables y evitará crear una etiqueta distinta para cada situación particular. ## 9.4. Estructura principal del catálogo El catálogo puede organizarse en siete colecciones principales: 1. Patrones. 2. Plantillas. 3. Componentes e implementaciones. 4. Criterios y decisiones arquitectónicas. 5. Prompts y automatizaciones. 6. Casos de aplicación. 7. Lecciones aprendidas. Estas colecciones no representan silos. Cada activo debe relacionarse con los demás cuando corresponda. ## 9.5. Colección de patrones La colección de patrones constituye el núcleo del catálogo. Cada patrón representa una solución reutilizable para una necesidad recurrente. ### Ficha mínima de un patrón #### Identificación - Nombre del patrón. - Código o identificador. - Estado. - Versión. - Responsable. - Fecha de última revisión. #### Definición - Problema que resuelve. - Propósito. - Resultado esperado. - Contextos de uso. - Situaciones en las que no debe utilizarse. #### Criterios - Criterios obligatorios. - Criterios recomendados. - Elementos adaptables. - Restricciones conocidas. - Riesgos principales. #### Aplicación - Información de entrada necesaria. - Plantillas relacionadas. - Componentes disponibles. - Implementaciones compatibles. - Pasos generales de aplicación. - Forma de validación. #### Evidencia - Casos de aplicación. - Lecciones aprendidas. - Variaciones conocidas. - Resultados o beneficios observados. La ficha debe permitir comprender el patrón sin necesidad de revisar primero el código. ## 9.6. Colección de plantillas Las plantillas facilitan la aplicación de uno o varios patrones en situaciones recurrentes. ### Ficha mínima de una plantilla - Nombre. - Propósito. - Patrones incluidos. - Tipo de curso o sección al que se aplica. - Información necesaria para utilizarla. - Elementos obligatorios. - Elementos opcionales. - Elementos que pueden personalizarse. - Componentes relacionados. - Instrucciones básicas. - Restricciones. - Estado y versión. - Ejemplo de uso. ### Tipos iniciales de plantillas CAPS puede comenzar con plantillas para: - Página de bienvenida. - Presentación general del curso. - Unidad de aprendizaje. - Lecturas y recursos complementarios. - Cronograma. - Presentación del profesor. - Actividades. - Evaluación. - Cierre o síntesis de unidad. No es necesario construir todas desde el inicio. Deben priorizarse aquellas que aparezcan con mayor frecuencia en los proyectos reales. ## 9.7. Colección de componentes e implementaciones Esta colección conserva las piezas concretas utilizadas para materializar los patrones. Puede incluir: - Listas. - Tarjetas. - Banners. - Botones. - Acordeones. - Carruseles. - Bloques informativos. - Estructuras de navegación. - Recursos embebidos. - Fragmentos HTML. - Estilos. - Configuraciones de Moodle. - Scripts autorizados. - Recursos H5P. - Elementos gráficos. ### Ficha mínima de un componente - Nombre del componente. - Patrón o patrones que implementa. - Propósito funcional. - Estado. - Versión. - Responsable. - Tecnología utilizada. - Instrucciones básicas. - Dependencias. - Elementos editables. - Elementos que deben conservarse. - Compatibilidad conocida. - Restricciones. - Riesgos. - Ejemplo funcional. - Criterios de validación. - Alternativas disponibles. ### Distinción entre componente e implementación El componente representa una pieza reutilizable desde el punto de vista funcional. La implementación representa su materialización en una tecnología determinada. Por ejemplo: - **Componente:** lista de recursos académicos. - **Implementación A:** lista HTML compatible con Moodle. - **Implementación B:** bloque nativo de Moodle. - **Implementación C:** tarjetas responsivas. Esta distinción permite conservar diferentes alternativas sin presentarlas como patrones independientes. ## 9.8. Colección de criterios y decisiones arquitectónicas ### Criterios Pueden organizarse en cuatro categorías: - Pedagógicos. - Organización de información. - Experiencia visual y accesibilidad. - Técnicos y de mantenimiento. Cada criterio debe indicar: - Qué exige o recomienda. - Por qué es importante. - A qué activos se aplica. - Si es obligatorio, recomendado o contextual. - Cómo puede verificarse. - Qué excepciones existen. ### Decisiones arquitectónicas Cada decisión deberá registrar: - Título. - Situación o problema. - Decisión adoptada. - Razón. - Alternativas consideradas. - Consecuencias. - Activos afectados. - Fecha. - Responsable de la decisión. - Condiciones para revisarla. Esta colección permite conservar el razonamiento detrás de CAPS y no únicamente sus resultados visibles. ## 9.9. Colección de prompts y automatizaciones Esta colección organiza el uso institucional de inteligencia artificial y automatización. No debe convertirse en una lista de instrucciones sueltas. Cada prompt debe relacionarse con una tarea, un patrón y unos criterios. ### Ficha mínima de un prompt - Nombre. - Tarea que realiza. - Patrón relacionado. - Usuario previsto. - Información de entrada. - Instrucción completa. - Formato de salida. - Criterios que debe respetar. - Aspectos que requieren revisión humana. - Herramienta o modelo en el que se ha probado. - Limitaciones. - Ejemplo de entrada. - Ejemplo de salida validada. - Estado. - Versión. - Responsable. ### Ficha mínima de una automatización Además de la información anterior, deberá indicar: - Evento o acción que la inicia. - Sistemas involucrados. - Dependencias. - Excepciones conocidas. - Mecanismo de recuperación ante errores. - Información que registra. - Riesgos. - Responsable de mantenimiento. ### Regla de incorporación Un prompt o automatización no debe clasificarse como validado únicamente porque produjo un resultado útil una vez. Debe comprobarse que: - Funciona de manera suficientemente consistente. - Respeta los criterios de CAPS. - Puede ser utilizado por otras personas. - Incluye revisión humana cuando corresponda. - Aporta un beneficio real sobre el proceso manual. ## 9.10. Colección de casos de aplicación Los casos muestran cómo se utilizaron los patrones en situaciones reales. ### Ficha mínima de un caso - Curso o proyecto. - Necesidad atendida. - Patrón utilizado. - Plantilla y componentes aplicados. - Adaptaciones realizadas. - Restricciones encontradas. - Resultado. - Tiempo o esfuerzo observado. - Problemas detectados. - Aprendizajes. - Activos que deben actualizarse. - Evidencias disponibles. Los casos no deben convertirse en informes extensos. Su función es aportar contexto y evidencia para mejorar la reutilización. ## 9.11. Colección de lecciones aprendidas Las lecciones aprendidas conservan conocimiento derivado de la experiencia. ### Ficha mínima de una lección - Situación. - Qué ocurrió. - Causa identificada. - Consecuencia. - Aprendizaje. - Recomendación. - Patrón o activo relacionado. - Acción propuesta. - Estado de la acción. ### Tipos de lección Una lección puede clasificarse como: - Prevención de error. - Mejora de calidad. - Reducción de tiempo. - Restricción técnica. - Mejora pedagógica. - Mejora visual o de accesibilidad. - Mejora de coordinación. - Uso de inteligencia artificial. - Mantenimiento. La lección se considera incorporada cuando produce una modificación concreta en el sistema o queda relacionada con una decisión pendiente. ## 9.12. Identificación y nombres Los nombres deben ayudar a comprender el propósito del activo. ### Convención para patrones Se recomienda utilizar nombres orientados a la necesidad o al resultado: - Organización de lecturas y recursos. - Presentación del equipo docente. - Orientación inicial de una unidad. - Comunicación de fechas y cronogramas. - Integración de contenido externo. - Navegación de retorno. - Presentación de información extensa. Deben evitarse nombres basados exclusivamente en la apariencia o la tecnología, como: - Carrusel azul. - Código nuevo. - Tarjeta versión final. - Lista bonita. - HTML actualizado. ### Identificador CAPS puede utilizar un identificador breve: - `PAT-001` para patrones. - `TPL-001` para plantillas. - `CMP-001` para componentes. - `IMP-001` para implementaciones. - `CRI-001` para criterios. - `ADR-001` para decisiones arquitectónicas. - `PRM-001` para prompts. - `CAS-001` para casos. - `LEC-001` para lecciones. El identificador facilita las relaciones y evita confusiones cuando cambien los nombres. No es indispensable utilizar códigos desde el primer día, pero resultarán útiles cuando crezca el catálogo. ## 9.13. Clasificación mínima Para facilitar la consulta, cada activo puede clasificarse mediante pocas dimensiones. ### Tipo de activo Patrón, plantilla, componente, implementación, criterio, decisión, prompt, caso o lección. ### Pilar principal - Conocimiento. - Producción. - Pedagogía. - Experiencia y comunicación visual. - Técnica y componentes. - Automatización e inteligencia artificial. ### Necesidad de producción - Orientación. - Organización de contenidos. - Lecturas y recursos. - Navegación. - Comunicación. - Actividades. - Evaluación. - Presentación de personas. - Interacción. - Integración técnica. - Accesibilidad. ### Momento del curso - Inicio. - Desarrollo. - Evaluación. - Cierre. - Transversal. ### Estado - Candidato. - En prueba. - Validado. - Retirado. ### Nivel de riesgo - Bajo. - Medio. - Alto. Estas dimensiones son suficientes para comenzar. Nuevas clasificaciones deben agregarse únicamente cuando exista una necesidad de búsqueda real. ## 9.14. Relaciones entre activos El valor del catálogo depende de sus relaciones. ### Relaciones principales Un patrón: - Puede utilizar varias plantillas. - Puede implementarse con varios componentes. - Debe cumplir varios criterios. - Puede tener diferentes variaciones. - Puede aparecer en distintos casos. - Puede generar lecciones aprendidas. - Puede contar con prompts asociados. Una plantilla: - Puede integrar varios patrones. - Utiliza componentes. - Se aplica en tipos concretos de cursos o secciones. Un componente: - Implementa uno o varios patrones. - Puede tener varias implementaciones tecnológicas. - Está sujeto a criterios técnicos, visuales y de accesibilidad. Una lección: - Puede modificar un patrón. - Puede corregir una implementación. - Puede originar un criterio. - Puede recomendar el retiro de un activo. Una decisión arquitectónica: - Puede afectar múltiples patrones, criterios y componentes. ### Regla de relación mínima Todo componente compartido debe relacionarse, como mínimo, con: - Un propósito. - Un patrón. - Una persona responsable. - Un estado. - Una implementación o ejemplo. Un componente sin estas relaciones continúa siendo un fragmento técnico, no un activo completo de CAPS. ## 9.15. Estados del ciclo de vida CAPS utilizará los cuatro estados definidos en su modelo operativo. ### Candidato El activo ha sido identificado, pero todavía no tiene suficiente evidencia o documentación. Puede consultarse, pero no debe presentarse como práctica recomendada. ### En prueba El activo se está evaluando en casos controlados. Debe indicar dónde se está utilizando y qué se busca comprobar. ### Validado El activo puede utilizarse regularmente dentro de las condiciones documentadas. Debe contar con: - Propósito claro. - Criterios. - Responsable. - Ejemplo. - Validación proporcional al riesgo. - Información de uso suficiente. ### Retirado El activo no debe utilizarse en nuevos proyectos. Debe señalar: - Motivo del retiro. - Alternativa recomendada. - Fecha. - Cursos o activos que todavía dependen de él. ### Transiciones La ruta esperada es: **Candidato → En prueba → Validado → Retirado** Un activo puede regresar de validado a en prueba si una modificación cambia significativamente su comportamiento. También puede retirarse directamente si se identifica un riesgo importante. ## 9.16. Versionamiento No todos los cambios requieren una nueva versión formal. ### Ajuste menor Corrige: - Errores de redacción. - Enlaces. - Imágenes. - Ejemplos. - Instrucciones sin impacto funcional. Puede registrarse mediante la fecha de actualización. ### Cambio funcional Modifica: - Estructura. - Comportamiento. - Criterios. - Compatibilidad. - Condiciones de uso. Debe generar una nueva versión del activo. ### Cambio incompatible Altera el uso de tal manera que cursos o implementaciones anteriores no pueden actualizarse automáticamente. Debe: - Crear una versión principal nueva. - Conservar la versión anterior como referencia. - Documentar el impacto. - Indicar una ruta de migración. CAPS no necesita adoptar inicialmente un sistema complejo de numeración. Puede comenzar con versiones como: - 1.0: primera versión validada. - 1.1: mejora compatible. - 2.0: cambio estructural o incompatible. ## 9.17. Vistas del catálogo Una misma base de activos puede presentarse mediante diferentes vistas. ### Vista por necesidad Permite buscar qué se quiere resolver. ### Vista por patrón Muestra patrones y sus activos asociados. ### Vista por momento del curso Agrupa activos para inicio, desarrollo, evaluación y cierre. ### Vista por disciplina Facilita consulta pedagógica, visual, técnica, operativa o de IA. ### Vista por estado Muestra candidatos, activos en prueba, validados y retirados. ### Vista por actualización Ayuda a identificar elementos recientemente modificados o pendientes de revisión. ### Vista por curso o proyecto Permite conocer qué patrones fueron aplicados y qué aprendizajes produjo un curso. Estas vistas no requieren duplicar la información. Son formas distintas de consultar la misma red de activos. ## 9.18. Búsqueda y recuperación El catálogo será útil cuando una persona pueda encontrar una solución sin conocer el nombre exacto del componente. La búsqueda debe reconocer: - Necesidades. - Sinónimos. - Tipos de contenido. - Momento del curso. - Tipo de interacción. - Tecnología. - Restricciones. - Estado. Por ejemplo, las búsquedas “bibliografía”, “lecturas”, “materiales obligatorios”, “recursos académicos” y “enlaces de consulta” deberían conducir al mismo patrón o a patrones relacionados. La curaduría deberá mantener etiquetas comprensibles y evitar términos excesivamente técnicos como única forma de acceso. ## 9.19. Migración del repositorio existente El repositorio actual contiene activos valiosos que pueden convertirse en la primera base del catálogo. La migración no debe consistir en copiar todos los fragmentos y asignarles una nueva etiqueta. Debe realizarse progresivamente. ### Etapa 1: Inventario Identificar: - Qué elementos existen. - Qué problema intentan resolver. - Qué elementos se encuentran duplicados. - Qué ejemplos continúan vigentes. - Qué implementaciones dependen de condiciones particulares. - Qué componentes se utilizan con mayor frecuencia. ### Etapa 2: Agrupación por necesidad Reunir componentes que resuelven problemas similares: - Listas de lecturas. - Presentaciones de profesores. - Cronogramas. - Botones de navegación. - Banners informativos. - Recursos embebidos. - Carruseles de contenido. ### Etapa 3: Identificación de patrones Para cada agrupación, determinar: - La necesidad común. - Los criterios compartidos. - Las diferencias relevantes. - Las variaciones útiles. - Los componentes que podrían consolidarse. ### Etapa 4: Evaluación técnica Revisar: - Compatibilidad. - Dependencias. - Código duplicado. - Accesibilidad. - Adaptabilidad. - Mantenimiento. - Uso de scripts. - Seguridad. ### Etapa 5: Clasificación Cada elemento puede quedar como: - Componente validado. - Implementación en prueba. - Ejemplo histórico. - Activo que requiere corrección. - Solución que debe retirarse. - Insumo para crear un patrón. ### Etapa 6: Documentación progresiva Comenzar con los elementos de mayor uso e impacto, sin intentar migrar todo el repositorio simultáneamente. ## 9.20. Ejemplo de estructura integrada ### Necesidad Presentar lecturas obligatorias y recursos complementarios. ### Patrón `PAT-001 — Organización de lecturas y recursos académicos` ### Criterios relacionados - Diferenciar recursos obligatorios y complementarios. - Identificar el tipo de recurso. - Presentar referencia bibliográfica suficiente. - Mantener una forma clara de acceso. - Evitar sobrecarga visual. - Comprobar enlaces. - Aplicar criterios de accesibilidad. ### Plantillas - `TPL-001 — Lista básica de lecturas` - `TPL-002 — Tarjetas de recursos académicos` - `TPL-003 — Presentación compacta para múltiples recursos` ### Componentes - Lista agrupada. - Tarjeta de recurso. - Icono de tipo de fuente. - Botón o enlace de consulta. ### Implementaciones - HTML compatible con Moodle. - Estructura mediante componentes nativos. - Variante responsiva para pantallas pequeñas. ### Prompt relacionado - Estructuración de referencias dentro de la plantilla validada. ### Casos - Curso de inducción. - Curso con lecturas académicas. - Curso con gran cantidad de recursos web. ### Lecciones - No todos los iconos de una biblioteca externa funcionan en Moodle. - Una lista extensa puede requerir una variación compacta. - Los enlaces deben validarse antes de publicar. Este ejemplo muestra que CAPS no guarda únicamente un código. Organiza toda la cadena de conocimiento alrededor de la necesidad. ## 9.21. Revisión y mantenimiento del catálogo El catálogo deberá revisarse periódicamente para identificar: - Activos que no se utilizan. - Fichas incompletas. - Implementaciones incompatibles. - Duplicaciones. - Patrones con demasiadas variaciones. - Elementos en prueba sin conclusión. - Prompts afectados por cambios de herramientas. - Componentes sin responsable. - Activos validados que necesitan actualización. - Lecciones pendientes de incorporación. La revisión no debe convertirse en una auditoría exhaustiva de todo el sistema. Puede concentrarse en: - Activos de mayor uso. - Activos de mayor riesgo. - Elementos modificados recientemente. - Candidatos que esperan validación. - Soluciones relacionadas con incidentes o retrabajos. ## 9.22. Requisitos de la herramienta de soporte CAPS puede implementarse inicialmente en Notion u otra plataforma disponible. La herramienta seleccionada debería permitir: - Crear fichas estructuradas. - Relacionar activos. - Filtrar por categorías. - Buscar por texto y etiquetas. - Mostrar estados. - Asignar responsables. - Conservar historial básico. - Adjuntar ejemplos y código. - Crear diferentes vistas. - Gestionar permisos. - Exportar o respaldar información. La arquitectura de CAPS no debe depender de funciones exclusivas de una sola plataforma. Si la herramienta cambia, los conceptos, relaciones y fichas deben poder trasladarse. ## 9.23. Antipatrones del catálogo CAPS debe evitar las siguientes prácticas. ### Guardar código sin propósito Un fragmento técnico no explica por qué ni cuándo debe utilizarse. ### Crear una ficha para cada variación mínima Produce fragmentación y dificulta encontrar la solución adecuada. ### Utilizar “final” como versión Nombres como “final”, “final nuevo” o “versión definitiva 2” no proporcionan trazabilidad. ### Duplicar activos para diferentes cursos Las adaptaciones particulares deben registrarse como casos o variaciones cuando corresponda. ### Conservar activos obsoletos como vigentes Los elementos retirados deben permanecer identificables, pero no aparecer como recomendados. ### Clasificar únicamente por disciplina Una persona debe poder buscar por necesidad, aunque no sepa si la solución es pedagógica, visual o técnica. ### Documentar sin ejemplos Una descripción conceptual sin aplicación puede resultar difícil de utilizar. ### Mostrar ejemplos sin criterios Un ejemplo aislado puede copiarse fuera de contexto. ### Permitir activos sin responsable El conocimiento pierde vigencia cuando nadie revisa sus cambios o restricciones. ## 9.24. Catálogo mínimo viable CAPS no necesita comenzar con todas sus colecciones completas. El catálogo mínimo viable puede contener: - Entre cinco y diez patrones de uso frecuente. - Una ficha breve para cada patrón. - Los componentes actualmente utilizados para implementarlos. - Criterios básicos. - Un caso de aplicación por patrón. - Estados visibles. - Un responsable por activo. - Una vista por necesidad. - Una vista por estado. Los primeros patrones pueden seleccionarse a partir de necesidades como: - Lecturas y recursos. - Presentación del profesor. - Cronograma. - Navegación. - Orientación de unidades. - Integración de recursos externos. - Comunicación de información importante. El catálogo deberá ampliarse a partir de la experiencia, no mediante un inventario teórico de todas las posibilidades. ## 9.25. Indicadores del catálogo ### Encontrabilidad Tiempo o facilidad con que una persona localiza un activo aplicable. ### Completitud Porcentaje de activos validados que cuentan con la información mínima. ### Reutilización Número de aplicaciones de patrones y componentes en diferentes cursos. ### Vigencia Cantidad de activos revisados y actualizados dentro del periodo definido. ### Duplicación Cantidad de soluciones similares que pueden consolidarse. ### Conversión Cantidad de candidatos que pasan a prueba, validación o retiro. ### Aprendizaje Número de lecciones que producen cambios concretos en activos. ### Dependencia Frecuencia con que una persona debe consultar directamente al autor para comprender un activo. El éxito no se mide por la cantidad total de fichas. Se mide por la capacidad del catálogo para facilitar decisiones y reducir trabajo repetitivo. ## 9.26. Criterios de éxito El catálogo cumplirá su función cuando: - Las personas puedan buscar desde una necesidad. - Los patrones se comprendan antes de revisar el código. - Los componentes indiquen claramente qué problema resuelven. - Las versiones vigentes sean fáciles de identificar. - Las restricciones y riesgos estén visibles. - Los casos ayuden a adaptar soluciones. - Los aprendizajes modifiquen el sistema. - Los activos retirados no se reutilicen accidentalmente. - Los nuevos integrantes puedan consultar el conocimiento con autonomía. - La IA pueda recuperar patrones y criterios estructurados. - El catálogo reduzca preguntas repetitivas y retrabajo. ## 9.27. Síntesis del modelo de catálogo El catálogo de CAPS organiza el conocimiento mediante una cadena de relaciones: > **Necesidad → patrón → criterios → plantilla → componente → implementación → caso → aprendizaje.** El patrón ocupa el centro porque conserva el conocimiento de la solución. Las plantillas y componentes facilitan su aplicación. Las implementaciones lo materializan en Moodle. Los casos muestran su comportamiento en contextos reales. Las lecciones permiten evolucionarlo. El catálogo no debe convertirse en un archivo de todo lo producido. Debe ser una selección organizada de conocimiento que ayude al área a tomar mejores decisiones y montar cursos con mayor consistencia, autonomía y eficiencia. --- # 10. Gobernanza y evolución de CAPS ## 10.1. Propósito de la gobernanza La gobernanza de CAPS establece cómo se toman, documentan y revisan las decisiones que afectan el framework. Su función es asegurar que: - Los activos mantengan calidad y vigencia. - Las contribuciones puedan incorporarse de manera ordenada. - Las innovaciones puedan probarse sin convertirse automáticamente en estándares. - Las decisiones importantes tengan responsables claros. - Los cambios conserven la integridad conceptual. - Las excepciones no fragmenten el sistema. - El conocimiento continúe evolucionando con la experiencia. La gobernanza no debe convertirse en una capa administrativa paralela a la producción. Debe integrarse al trabajo cotidiano mediante reglas simples, estados visibles y revisiones proporcionales al impacto. Su principio central es: > **CAPS debe controlar las decisiones de alto impacto y facilitar las decisiones de bajo riesgo.** ## 10.2. Objetivos de la gobernanza La gobernanza de CAPS busca alcanzar seis objetivos: ### Mantener la integridad conceptual Asegurar que los patrones, componentes y decisiones formen parte de una arquitectura común. ### Facilitar la contribución Permitir que diferentes perfiles propongan, prueben y mejoren soluciones. ### Proteger la calidad Verificar que los activos compartidos cumplan criterios pedagógicos, visuales, técnicos y operativos. ### Evitar la proliferación innecesaria Reducir duplicaciones, variaciones sin propósito y soluciones paralelas. ### Administrar el cambio Permitir que el framework evolucione sin perder trazabilidad ni afectar innecesariamente los cursos existentes. ### Favorecer la innovación controlada Crear un espacio seguro para experimentar antes de institucionalizar una solución. ## 10.3. Principios de gobernanza ### Proporcionalidad El nivel de revisión debe corresponder al riesgo y al impacto del cambio. Una corrección de texto no debe recibir el mismo tratamiento que un nuevo script utilizado en múltiples cursos. ### Transparencia Las decisiones relevantes deben indicar: - Qué se decidió. - Por qué se decidió. - Quién asumió la responsabilidad. - Qué activos resultan afectados. - Cuándo debería revisarse. ### Responsabilidad explícita Todo activo validado debe tener una persona o función responsable de su mantenimiento. ### Experimentación antes de estandarización Una solución nueva debe poder probarse sin presentarse inmediatamente como práctica institucional. ### Evidencia antes de expansión Los activos deben ampliarse o generalizarse a partir de casos reales, no solo por su atractivo conceptual o técnico. ### Simplicidad operativa La gobernanza debe utilizar el menor número de estados, documentos y espacios de decisión que resulte suficiente. ### Reversibilidad Cuando sea posible, los cambios deben permitir regresar a una versión anterior o sustituir una implementación sin perder el patrón. ### Aprendizaje continuo Las decisiones deben poder revisarse cuando aparezcan nuevos datos, tecnologías, restricciones o necesidades. ## 10.4. Objeto de la gobernanza No todas las actividades del área necesitan ser gobernadas por CAPS. La gobernanza se concentra en los activos que pueden afectar más de un curso o convertirse en conocimiento compartido. ### Elementos bajo gobernanza - Patrones. - Plantillas. - Componentes reutilizables. - Implementaciones técnicas compartidas. - Criterios. - Decisiones arquitectónicas. - Prompts validados. - Automatizaciones. - Variaciones recurrentes. - Estados y versiones. - Excepciones con posible impacto transversal. ### Elementos fuera de la gobernanza central - Correcciones de contenido de un curso. - Ajustes de fechas. - Cambios de imágenes particulares. - Decisiones académicas exclusivas del experto. - Modificaciones locales que no alteren un activo compartido. - Adaptaciones permitidas dentro de una plantilla. Estos elementos siguen los procesos normales de producción y revisión del curso. ## 10.5. Niveles de decisión CAPS utilizará tres niveles de decisión. ### Nivel 1: Decisión local Corresponde a cambios que afectan únicamente un curso y se mantienen dentro de los límites de un patrón validado. Ejemplos: - Cambiar textos. - Sustituir imágenes. - Actualizar fechas. - Modificar enlaces. - Ocultar un elemento opcional. - Seleccionar una variación ya aprobada. Puede decidir el responsable del montaje o de la entrega, según las responsabilidades del proyecto. No requiere registrarse en CAPS, salvo que produzca un aprendizaje relevante. ### Nivel 2: Decisión sobre un activo Corresponde a cambios que afectan una plantilla, componente, prompt, criterio o implementación reutilizable. Ejemplos: - Corregir un componente compartido. - Crear una nueva variación. - Modificar un prompt. - Mejorar una plantilla. - Actualizar instrucciones. - Cambiar una dependencia técnica. - Incorporar un nuevo caso de uso. Requiere: - Responsable del activo. - Revisión de la especialidad afectada. - Actualización por curaduría. La función de arquitectura participa cuando el cambio afecta la relación con otros patrones o criterios. Debe quedar documentada la versión, el motivo y el impacto. ### Nivel 3: Decisión arquitectónica o estratégica Corresponde a cambios que afectan varios activos, pilares, procesos o responsabilidades. Ejemplos: - Crear una nueva categoría de patrones. - Cambiar un principio arquitectónico. - Adoptar un sistema general de componentes. - Incorporar una nueva tecnología transversal. - Modificar la estructura de navegación institucional. - Establecer restricciones generales sobre scripts. - Cambiar la herramienta principal del catálogo. - Automatizar una fase completa de producción. Requiere: - Análisis del responsable de arquitectura. - Consulta a los especialistas afectados. - Decisión de la orientación estratégica cuando exista impacto institucional, presupuestal o de responsabilidades. Debe documentarse como decisión arquitectónica. ## 10.6. Flujo mínimo para incorporar un activo ### Paso 1: Propuesta Una persona identifica: - Un problema recurrente. - Una solución que podría reutilizarse. - Una mejora relevante. - Una oportunidad de automatización. - Una restricción que requiere atención. La propuesta debe describir primero la necesidad y después la solución. ### Paso 2: Revisión inicial Se determina: - Si existe un activo similar. - Si la necesidad es realmente recurrente. - Si puede integrarse a un patrón existente. - Qué riesgo presenta. - Qué tipo de prueba requiere. ### Paso 3: Clasificación como candidato La solución se incorpora al catálogo con información mínima y estado de candidato. ### Paso 4: Prueba controlada Se utiliza en uno o varios casos concretos. La prueba debe observar: - Utilidad. - Claridad. - Funcionamiento. - Adaptabilidad. - Mantenimiento. - Riesgos. - Beneficio en tiempo o calidad. ### Paso 5: Validación Los especialistas correspondientes revisan los resultados. ### Paso 6: Decisión El activo puede ser: - Validado. - Mantenido en prueba. - Devuelto para ajustes. - Integrado a otro activo. - Rechazado. - Retirado. ### Paso 7: Publicación La curaduría actualiza: - Estado. - Versión. - Responsable. - Relaciones. - Evidencia. - Fecha de revisión. ## 10.7. Criterios para aprobar un activo Un activo puede validarse cuando cumple suficientemente los siguientes criterios: - **Necesidad:** resuelve un problema real y suficientemente recurrente. - **Claridad:** otra persona puede comprender su propósito y utilizarlo. - **Coherencia:** respeta los principios y patrones relacionados. - **Utilidad:** aporta una mejora verificable en calidad, tiempo, claridad o reutilización. - **Pertinencia:** resulta adecuado para los contextos documentados. - **Funcionamiento:** opera correctamente dentro de las condiciones técnicas previstas. - **Sostenibilidad:** puede mantenerse sin una dependencia o complejidad desproporcionada. - **Adaptabilidad:** permite las variaciones necesarias sin perder su propósito. - **Evidencia:** ha sido probado o cuenta con una validación acorde con su riesgo. - **Responsabilidad:** tiene una persona o función responsable. No se requiere perfección absoluta. Se requiere suficiente confianza para permitir su reutilización en las condiciones establecidas. ## 10.8. Validación proporcional al riesgo ### Riesgo bajo Incluye: - Plantillas conocidas. - Componentes sin comportamiento dinámico. - Ajustes visuales menores. - Prompts para tareas de apoyo sin publicación automática. - Variaciones que conservan la estructura validada. Revisión requerida: - Verificación funcional básica. - Revisión del responsable del activo. - Registro mínimo. ### Riesgo medio Incluye: - Nuevos componentes visuales. - Cambios estructurales. - Integración de recursos externos conocidos. - Prompts que generan contenidos o código. - Variaciones con impacto en navegación o experiencia. Revisión requerida: - Revisión de la especialidad correspondiente. - Prueba en un caso real. - Validación en Moodle. - Registro de restricciones. ### Riesgo alto Incluye: - Scripts. - Automatizaciones de publicación. - Integraciones con sistemas externos. - Cambios que afectan múltiples cursos. - Soluciones que manejan información sensible. - Modificaciones de navegación transversal. - Automatizaciones que toman decisiones sin intervención inmediata. Revisión requerida: - Validación técnica rigurosa. - Revisión arquitectónica. - Pruebas controladas. - Plan de reversión. - Documentación de riesgos. - Aprobación estratégica cuando corresponda. ## 10.9. Gestión de excepciones Una excepción ocurre cuando un curso necesita apartarse de un patrón o criterio validado. Las excepciones no son necesariamente errores. Pueden responder a necesidades legítimas que el sistema todavía no contempla. ### Información mínima de una excepción - Qué patrón o criterio no puede aplicarse. - Qué necesidad particular existe. - Por qué la solución estándar resulta insuficiente. - Qué alternativa se propone. - Qué riesgo introduce. - Si la modificación es temporal o permanente. - Quién asume la decisión. - Qué aprendizaje podría generar. ### Tipos de excepción **Excepción local:** aplica a un único curso y no justifica cambiar CAPS. Debe documentarse dentro del proyecto cuando resulte relevante. **Excepción recurrente:** aparece en varios proyectos y puede indicar que el patrón necesita una variación, que el criterio es demasiado restrictivo, que existe una tipología no contemplada o que se necesita un nuevo patrón. **Excepción crítica:** se aparta de un criterio por razones técnicas, de seguridad, accesibilidad o cumplimiento. Requiere revisión especializada y aprobación explícita. ### Regla fundamental > **Una excepción no modifica automáticamente el estándar, pero tampoco debe ignorarse si se repite.** ## 10.10. Gestión de innovación CAPS debe facilitar la innovación sin permitir que cada experimento se convierta en una nueva regla. ### Espacio de experimentación Las soluciones nuevas pueden desarrollarse como: - Candidatos. - Prototipos. - Pruebas controladas. - Variaciones temporales. - Casos piloto. ### Condiciones mínimas Toda experimentación debe indicar: - Problema que busca resolver. - Hipótesis de mejora. - Contexto de prueba. - Riesgos. - Criterios para evaluar el resultado. - Persona responsable. - Forma de volver a una solución anterior. ### Resultados posibles Una innovación puede: - Convertirse en un activo validado. - Integrarse como variación. - Mejorar un patrón existente. - Mantenerse para casos excepcionales. - Abandonarse. - Generar una lección aprendida. ### Principio de innovación > **Experimentar debe ser fácil; convertir un experimento en estándar requiere evidencia.** ## 10.11. Priorización de cambios CAPS no podrá desarrollar simultáneamente todas las propuestas. La priorización debe basarse en valor y recurrencia, no únicamente en interés técnico. ### Criterios de priorización - **Frecuencia:** ¿con qué frecuencia aparece la necesidad? - **Impacto:** ¿cuántos cursos, estudiantes, profesores o unidades podrían beneficiarse? - **Esfuerzo repetitivo:** ¿cuánto trabajo manual podría reducirse? - **Retrabajo:** ¿cuántos errores o correcciones podría prevenir? - **Riesgo:** ¿existe un problema de funcionamiento, accesibilidad, seguridad o calidad? - **Madurez:** ¿la solución ya ha sido probada o todavía es una idea inicial? - **Dependencia:** ¿otros patrones o capacidades necesitan este activo? - **Viabilidad:** ¿puede construirse y mantenerse con las capacidades disponibles? ### Categorías de prioridad - **Prioridad alta:** necesidad frecuente, impacto amplio y solución viable. - **Prioridad media:** necesidad relevante, pero con menor recurrencia o mayor incertidumbre. - **Prioridad exploratoria:** propuesta prometedora que necesita experimentación. - **No priorizada:** propuesta que puede conservarse como referencia, pero no justifica trabajo inmediato. ## 10.12. Mecanismo ligero de priorización Para evitar modelos complejos, cada propuesta puede evaluarse inicialmente mediante cuatro preguntas: 1. ¿Se repite? 2. ¿Reduce tiempo o retrabajo? 3. ¿Mejora calidad, claridad o accesibilidad? 4. ¿Puede mantenerse razonablemente? Las propuestas que respondan positivamente a varias de estas preguntas pueden avanzar. No es necesario asignar puntuaciones detalladas en la primera etapa de CAPS. ## 10.13. Gestión de versiones y cambios La gobernanza debe permitir identificar qué versión está vigente y qué cambió. ### Registro mínimo de cambio Todo cambio funcional debe indicar: - Activo afectado. - Versión anterior. - Versión nueva. - Motivo. - Descripción del cambio. - Impacto esperado. - Responsable. - Fecha. - Necesidad de actualizar implementaciones existentes. ### Compatibilidad Antes de publicar una nueva versión debe determinarse si: - Es completamente compatible. - Requiere ajustes menores. - Requiere migración. - Solo aplica a nuevos cursos. ### Versiones anteriores Las versiones anteriores no deben eliminarse inmediatamente cuando existan cursos que todavía dependan de ellas. Deben marcarse como: - Vigentes. - En transición. - Retiradas. - Conservadas por compatibilidad. ## 10.14. Retiro de activos Retirar un activo es una decisión normal dentro de un sistema que evoluciona. Un activo puede retirarse cuando: - Presenta riesgos. - Dejó de ser compatible. - Fue reemplazado por una solución más simple. - Duplica otro activo. - No cumple criterios de accesibilidad. - Su mantenimiento es excesivo. - Depende de una herramienta descontinuada. - No se utiliza. - Produce errores recurrentes. ### Información de retiro Debe documentarse: - Motivo. - Fecha. - Alternativa recomendada. - Cursos posiblemente afectados. - Acciones de migración. - Persona responsable. - Periodo de transición, cuando corresponda. Un activo retirado se conserva como referencia histórica, pero no aparece como opción recomendada. ## 10.15. Revisiones de gobernanza CAPS puede funcionar con tres espacios de revisión. ### Revisión operativa de candidatos Propósito: - Analizar nuevos activos. - Resolver dudas de clasificación. - Determinar pruebas. - Identificar revisores. Debe ser breve y convocarse según el volumen de propuestas. ### Revisión periódica del catálogo Propósito: - Revisar activos en prueba. - Detectar obsolescencia. - Cerrar candidatos antiguos. - Identificar duplicaciones. - Revisar patrones de mayor uso. - Verificar responsables. Puede realizarse con una periodicidad amplia, evitando reuniones innecesarias. ### Revisión estratégica Propósito: - Evaluar beneficios. - Revisar prioridades. - Resolver decisiones transversales. - Analizar necesidades de inversión. - Revisar la evolución de capacidades. - Alinear CAPS con la estrategia del área. La frecuencia debe definirse según el ciclo de planeación institucional. ## 10.16. Decisiones arquitectónicas documentadas Las decisiones de alto impacto deben registrarse mediante una ficha breve. ### Plantilla de decisión arquitectónica - **Título:** nombre comprensible de la decisión. - **Situación:** problema o necesidad que la origina. - **Decisión:** qué se ha determinado. - **Razón:** por qué se elige esta alternativa. - **Alternativas consideradas:** qué otras opciones fueron evaluadas. - **Consecuencias:** beneficios, costos, riesgos y restricciones. - **Activos afectados:** patrones, plantillas, componentes o procesos relacionados. - **Responsable:** quién toma o mantiene la decisión. - **Fecha de revisión:** cuándo o bajo qué condición debería evaluarse nuevamente. La ficha debe preservar el razonamiento sin convertirse en un informe extenso. ## 10.17. Gestión de desacuerdos Los desacuerdos son esperables cuando participan distintas disciplinas. CAPS debe resolverlos desde el propósito y los criterios, no desde la jerarquía personal o la preferencia estética. ### Secuencia de resolución 1. Identificar la necesidad común. 2. Diferenciar hechos, restricciones y preferencias. 3. Revisar principios y criterios aplicables. 4. Evaluar impacto en estudiantes, producción y mantenimiento. 5. Probar alternativas cuando exista incertidumbre. 6. Escalar únicamente si la decisión es transversal o estratégica. 7. Registrar la decisión cuando pueda repetirse. ### Criterio de desempate Cuando dos soluciones resulten razonables, deberá preferirse la que: - Sea más comprensible. - Introduzca menor complejidad. - Sea más fácil de mantener. - Pueda reutilizarse. - Conserve mejor la integridad conceptual. - Permita reversión. - Tenga menor riesgo. ## 10.18. Gobierno de la inteligencia artificial El uso de IA requiere reglas específicas porque puede producir resultados con rapidez y alta variabilidad. ### Activos de IA bajo gobierno - Prompts. - Instrucciones de sistema. - Bases de conocimiento. - Flujos automatizados. - Plantillas de entrada. - Validadores. - Salidas reutilizables. - Integraciones con Moodle u otras herramientas. ### Controles mínimos Todo uso compartido debe definir: - Propósito. - Usuario previsto. - Información permitida. - Patrón relacionado. - Criterios de salida. - Revisión humana. - Limitaciones. - Herramienta probada. - Responsable. - Estado. ### Acciones que no deben automatizarse sin control explícito - Publicación definitiva. - Aprobación académica. - Validación de accesibilidad final. - Decisiones de seguridad. - Creación autónoma de estándares. - Modificación de múltiples cursos sin revisión. - Uso de información sensible sin autorización. - Retiro o sustitución automática de activos. ### Principio de control > **La IA puede ejecutar y recomendar; la responsabilidad de validar y decidir permanece en las personas.** ## 10.19. Trazabilidad mínima CAPS no necesita registrar cada interacción, pero sí debe conservar trazabilidad de las decisiones relevantes. Como mínimo debe ser posible conocer: - Cuál es la versión vigente. - Quién mantiene el activo. - Cuándo se modificó. - Por qué se modificó. - Qué decisión respaldó el cambio. - En qué casos se ha utilizado. - Qué restricciones se conocen. - Qué alternativa existe si se retira. La trazabilidad debe ayudar a comprender el sistema, no convertirse en un archivo administrativo sin uso. ## 10.20. Indicadores de gobernanza - **Tiempo de decisión:** tiempo requerido para resolver propuestas según su nivel de riesgo. - **Candidatos abiertos:** cantidad de activos candidatos sin una acción o conclusión definida. - **Conversión:** proporción de candidatos que pasan a prueba, validación o retiro. - **Vigencia:** porcentaje de activos prioritarios revisados dentro del periodo establecido. - **Excepciones recurrentes:** cantidad de excepciones que indican necesidad de modificar un patrón. - **Incidentes:** errores o retrabajos originados por activos compartidos. - **Concentración de decisiones:** porcentaje de decisiones que dependen de una sola persona. - **Innovación adoptada:** cantidad de experimentos que generaron una mejora reutilizable. El objetivo no es maximizar el número de aprobaciones. Es conseguir decisiones claras, oportunas y sostenibles. ## 10.21. Criterios de una gobernanza saludable La gobernanza funcionará adecuadamente cuando: - Los cambios locales puedan realizarse con autonomía. - Los activos compartidos tengan responsables. - Las decisiones de alto impacto sean visibles. - Las revisiones se ajusten al riesgo. - Los experimentos tengan una ruta clara. - Las excepciones recurrentes produzcan aprendizaje. - Los activos obsoletos se retiren. - Los desacuerdos se resuelvan mediante criterios. - La arquitectura no dependa exclusivamente de una persona. - La gobernanza no retrase innecesariamente la producción. - Los equipos comprendan qué pueden modificar y qué deben conservar. ## 10.22. Antipatrones de gobernanza ### Aprobar todo mediante comité Genera demoras y traslada decisiones simples a espacios innecesarios. ### Permitir que todo se convierta en estándar Multiplica soluciones y fragmenta el catálogo. ### Centralizar el conocimiento en el arquitecto Convierte la función de arquitectura en un nuevo punto de dependencia. ### Mantener experimentos indefinidamente Los activos en prueba deben concluir en validación, modificación o retiro. ### Crear normas sin evidencia Las reglas deben responder a problemas reales y aprendizajes observados. ### Conservar activos por apego histórico El valor anterior no garantiza la vigencia futura. ### Confundir gobernanza con control de personas CAPS gobierna activos, criterios y decisiones; no busca vigilar cada acción del equipo. ### Automatizar las aprobaciones conceptuales La consistencia técnica no sustituye la pertinencia pedagógica ni la decisión institucional. ## 10.23. Gobernanza mínima viable Durante la primera etapa, CAPS puede operar con una gobernanza reducida: - Un responsable estratégico. - Un responsable de arquitectura y catálogo. - Revisores por especialidad. - Cuatro estados: candidato, en prueba, validado y retirado. - Tres niveles de decisión: local, de activo y arquitectónico o estratégico. - Dos espacios periódicos: revisión de candidatos y revisión estratégica. - Una ficha breve de decisión para cambios transversales. Esta estructura resulta suficiente para iniciar y puede ampliarse cuando el volumen real lo justifique. ## 10.24. Evolución de la gobernanza ### Etapa inicial Características: - Pocos patrones. - Responsabilidades combinadas. - Validación manual. - Decisiones cercanas al equipo. - Uso de una herramienta sencilla. Prioridad: - Claridad conceptual. - Adopción. - Aprendizaje. ### Etapa de consolidación Características: - Mayor catálogo. - Más contribuidores. - Roles diferenciados. - Versionamiento más formal. - Revisión periódica. - Primeras automatizaciones. Prioridad: - Consistencia. - Encontrabilidad. - Reducción de duplicación. - Medición de beneficios. ### Etapa de escalamiento Características: - Uso en numerosos cursos. - Integración con flujos de producción. - Automatización de consultas y validaciones. - Participación de varias áreas. - Mayor dependencia institucional. Prioridad: - Sostenibilidad. - Gestión de cambios. - Distribución de responsabilidades. - Integración tecnológica. - Continuidad operativa. El crecimiento de la gobernanza debe responder a la complejidad real y no anticiparla innecesariamente. ## 10.25. Síntesis de la gobernanza La gobernanza de CAPS se fundamenta en una idea sencilla: > **La innovación debe poder entrar al sistema con facilidad, pero los estándares deben construirse con criterio, evidencia y responsabilidad.** CAPS protege su integridad mediante: - Niveles de decisión. - Validación proporcional al riesgo. - Estados de madurez. - Responsables visibles. - Registro de decisiones transversales. - Gestión de excepciones. - Experimentación controlada. - Versionamiento y retiro. - Aprendizaje continuo. La gobernanza no busca reducir la autonomía. Busca crear condiciones para que la autonomía de diferentes personas produzca soluciones compatibles y fortalezca la capacidad del área. --- # 11. Modelo de madurez y medición de CAPS ## 11.1. Propósito del modelo El modelo de madurez permite reconocer cómo evoluciona CAPS desde un conjunto inicial de recursos dispersos hasta convertirse en una capacidad institucional integrada a la producción de cursos. Su finalidad no es asignar una calificación al equipo ni comparar personas. Busca responder preguntas estratégicas: - ¿Qué capacidades existen actualmente? - ¿Cuáles dependen todavía del conocimiento individual? - ¿Qué prácticas ya son reutilizables? - ¿Qué beneficios está produciendo CAPS? - ¿Dónde conviene concentrar el siguiente esfuerzo? - ¿Qué nivel de organización necesita realmente el área? - ¿Cuándo resulta razonable incorporar más automatización? El modelo debe ayudar a tomar decisiones, no producir reportes extensos. Su principio rector es: > **La madurez de CAPS no se mide por la cantidad de activos almacenados, sino por la capacidad del área para encontrarlos, aplicarlos, mejorarlos y convertirlos en resultados consistentes.** ## 11.2. Madurez y rendimiento ### Madurez Indica qué tan estable, organizada y sostenible es una capacidad. Por ejemplo: - Existen patrones documentados. - Hay responsables identificados. - Los activos tienen estados. - Las personas conocen el lenguaje común. - Las decisiones se encuentran registradas. - Los aprendizajes regresan al sistema. ### Rendimiento Indica qué resultados produce esa capacidad en la operación. Por ejemplo: - Reducción del tiempo de montaje. - Menor cantidad de correcciones. - Mayor reutilización. - Mejor previsibilidad. - Mayor volumen atendido. - Mayor satisfacción de las áreas solicitantes. Una capacidad puede estar bien documentada y todavía no producir resultados significativos porque su adopción es baja. También puede producir resultados iniciales gracias al esfuerzo de algunas personas sin ser todavía sostenible. CAPS debe medir ambas dimensiones. ## 11.3. Estructura del modelo de madurez Para conservar simplicidad, CAPS utilizará cuatro niveles: 1. **Inicial** 2. **Organizado** 3. **Integrado** 4. **Adaptativo** Los niveles no representan fechas ni etapas obligatorias para todos los pilares al mismo tiempo. CAPS puede encontrarse, por ejemplo: - En nivel organizado para componentes técnicos. - En nivel inicial para prompts de inteligencia artificial. - En nivel integrado para patrones de lecturas. - En nivel inicial para medición de resultados. El propósito no es alcanzar rápidamente el nivel más alto en todo. Es desarrollar la madurez necesaria para responder a las necesidades reales del área. ## 11.4. Nivel 1: Inicial ### Descripción El conocimiento existe principalmente en personas, documentos, fragmentos de código, conversaciones y ejemplos de cursos anteriores. Las soluciones pueden ser útiles, pero su aplicación depende del conocimiento de quienes las crearon o las han utilizado previamente. ### Características - Existen ejemplos y componentes dispersos. - No siempre está documentado qué problema resuelven. - Se utilizan nombres y conceptos diferentes para soluciones similares. - La reutilización ocurre mediante copia o consulta directa a otra persona. - Las decisiones se repiten entre proyectos. - Las variaciones no están claramente identificadas. - La validación depende de la experiencia individual. - La IA se utiliza mediante instrucciones particulares. - Los tiempos y retrabajos no se miden de manera consistente. - La continuidad depende de personas específicas. ### Valor existente Este nivel no significa ausencia de conocimiento. Por el contrario, puede existir una experiencia considerable. El problema es que la experiencia todavía no se encuentra convertida en una capacidad compartida y sostenible. ### Prioridad La prioridad es hacer visible y comprensible el conocimiento de mayor uso. ### Evidencia de avance - Inventario inicial. - Identificación de necesidades recurrentes. - Selección de los primeros patrones. - Acuerdo sobre vocabulario básico. - Asignación de responsables iniciales. ## 11.5. Nivel 2: Organizado ### Descripción El área ha comenzado a transformar recursos dispersos en activos documentados y consultables. Ya existe una estructura común, aunque su uso puede concentrarse en algunos proyectos o personas. ### Características - Existe un catálogo inicial. - Los patrones prioritarios cuentan con fichas básicas. - Los componentes se relacionan con necesidades concretas. - Se diferencian patrones, plantillas e implementaciones. - Los activos tienen estados visibles. - Existen criterios mínimos de validación. - Se han identificado responsables. - Se registran algunos casos y lecciones. - La IA comienza a utilizar prompts vinculados con patrones. - Se cuenta con una línea base de tiempos o retrabajos. - Los nuevos activos siguen una ruta básica de incorporación. ### Prioridad La prioridad es lograr adopción y comprobar que la estructura resulta útil para el trabajo real. ### Evidencia de avance - Cinco a diez patrones prioritarios documentados. - Uso del catálogo en cursos reales. - Primeras plantillas validadas. - Componentes duplicados identificados. - Primeros indicadores operativos. - Revisiones periódicas de candidatos. - Casos que demuestran reutilización. ## 11.6. Nivel 3: Integrado ### Descripción CAPS forma parte habitual del proceso de producción. Las personas consultan y aplican los patrones como parte del trabajo cotidiano. El conocimiento generado en los proyectos regresa de manera sistemática al framework. ### Características - CAPS se consulta desde el inicio de las solicitudes. - La mayoría de las necesidades recurrentes tienen patrones aplicables. - Los activos están integrados al ciclo de producción. - Los cambios de alto impacto se documentan. - La validación se realiza según el nivel de riesgo. - Las áreas utilizan un lenguaje común. - Los patrones cuentan con varias aplicaciones reales. - Los activos obsoletos se retiran de manera controlada. - Los nuevos integrantes pueden trabajar con menor dependencia. - Los prompts y automatizaciones utilizan conocimiento validado. - Los indicadores muestran beneficios en reutilización, tiempo o calidad. - Las prioridades de CAPS se relacionan con las necesidades del área. ### Prioridad La prioridad es consolidar consistencia, sostenibilidad y medición de beneficios. ### Evidencia de avance - Uso habitual en diferentes tipos de cursos. - Reducción comprobable de decisiones repetitivas. - Menor tiempo en montajes recurrentes. - Disminución de errores previsibles. - Mayor autonomía de los contribuidores. - Responsabilidades distribuidas. - Automatizaciones controladas en tareas estables. - Revisión regular de activos prioritarios. ## 11.7. Nivel 4: Adaptativo ### Descripción CAPS funciona como una capacidad institucional que aprende y se adapta de manera continua. El sistema no solo conserva soluciones existentes. Puede detectar necesidades emergentes, orientar nuevas formas de producción y ampliar la capacidad del área mediante conocimiento estructurado y automatización responsable. ### Características - Los datos de producción orientan la evolución de los patrones. - Las necesidades recurrentes pueden detectarse sistemáticamente. - El catálogo se encuentra integrado con herramientas de trabajo. - La IA puede consultar y aplicar patrones bajo controles definidos. - Existen automatizaciones para tareas estables y repetitivas. - Las decisiones se toman con evidencia de uso, calidad y mantenimiento. - El aprendizaje de diferentes cursos se consolida transversalmente. - CAPS puede adaptarse a nuevos tipos de cursos o plataformas. - Las responsabilidades no dependen de una única persona. - El framework influye en la planeación del área. - La institución reconoce CAPS como una capacidad estratégica. - La mejora del sistema es parte natural de la producción. ### Prioridad La prioridad es mantener adaptabilidad sin aumentar innecesariamente la complejidad. ### Evidencia de avance - Automatizaciones conectadas con activos validados. - Uso transversal en múltiples programas o unidades. - Decisiones orientadas por indicadores. - Capacidad para incorporar nuevas tecnologías sin perder coherencia. - Reducción sostenida del esfuerzo repetitivo. - Evolución de patrones basada en evidencia acumulada. - Transferencia efectiva del modelo a nuevos equipos. ## 11.8. Dimensiones de madurez ### Dimensión 1: Conocimiento Evalúa si la experiencia se encuentra organizada y disponible. Preguntas: - ¿Los problemas recurrentes están identificados? - ¿Existen patrones documentados? - ¿Los activos se encuentran relacionados? - ¿Las personas pueden encontrarlos? - ¿Las lecciones modifican el sistema? - ¿El conocimiento permanece cuando cambian las personas? ### Dimensión 2: Aplicación en producción Evalúa si CAPS forma parte del montaje cotidiano. Preguntas: - ¿Se consulta antes de construir una nueva solución? - ¿Los patrones se aplican en cursos reales? - ¿Las plantillas reducen decisiones repetitivas? - ¿El aprendizaje regresa al catálogo? - ¿Las excepciones se identifican? - ¿La producción puede anticipar mejor sus necesidades? ### Dimensión 3: Calidad e integridad conceptual Evalúa si las soluciones conservan criterios compartidos. Preguntas: - ¿Existen criterios claros? - ¿Los componentes responden a patrones? - ¿Las variaciones están justificadas? - ¿Las decisiones transversales están documentadas? - ¿Se mantiene coherencia pedagógica, visual y técnica? - ¿Se controlan accesibilidad, compatibilidad y mantenimiento? ### Dimensión 4: Organización y gobernanza Evalúa si las responsabilidades y decisiones son claras. Preguntas: - ¿Los activos tienen responsables? - ¿Se sabe quién puede proponer, revisar y decidir? - ¿Las revisiones son proporcionales al riesgo? - ¿Los candidatos llegan a una conclusión? - ¿Los activos obsoletos se retiran? - ¿La arquitectura puede mantenerse sin depender de una sola persona? ### Dimensión 5: Automatización e inteligencia artificial Evalúa si la tecnología amplifica conocimiento validado. Preguntas: - ¿Los prompts están relacionados con patrones? - ¿Las entradas y salidas están definidas? - ¿Existe revisión humana? - ¿Se conocen las limitaciones? - ¿La automatización reduce trabajo real? - ¿Se evita automatizar procesos todavía confusos? - ¿Los resultados generados mantienen la integridad conceptual? ### Dimensión 6: Medición y aprendizaje estratégico Evalúa si CAPS puede demostrar valor y orientar decisiones. Preguntas: - ¿Existe una línea base? - ¿Se miden tiempos de actividades recurrentes? - ¿Se identifican causas de retrabajo? - ¿Puede observarse la reutilización? - ¿Los datos orientan prioridades? - ¿Los resultados se comunican a la dirección? - ¿La medición conduce a decisiones concretas? ## 11.9. Evaluación ligera de madurez CAPS no necesita inicialmente una auditoría extensa. Cada dimensión puede evaluarse mediante cuatro descripciones: - **Inicial:** la práctica depende principalmente de iniciativas individuales. - **Organizada:** existe una forma común y documentada de realizarla. - **Integrada:** la práctica forma parte habitual de la producción. - **Adaptativa:** la práctica utiliza evidencia y aprendizaje para evolucionar. La evaluación debe acompañarse de ejemplos concretos. No basta con afirmar que una dimensión es integrada. Debe indicarse qué evidencia permite sostenerlo. ## 11.10. Línea base Antes de medir mejoras, CAPS necesita comprender la situación inicial. La línea base debe concentrarse en algunas actividades frecuentes, no en toda la producción. ### Información inicial sugerida Para un conjunto pequeño de cursos o solicitudes, registrar: - Tipo de solicitud. - Elementos montados. - Tiempo aproximado de montaje. - Número de personas involucradas. - Cantidad de revisiones. - Correcciones posteriores. - Componentes reutilizados. - Soluciones creadas desde cero. - Problemas repetidos. - Dependencias de personas específicas. - Uso de inteligencia artificial. - Percepción de dificultad. La línea base no requiere precisión absoluta. Su función es ofrecer una referencia suficientemente confiable para comparar la evolución. ## 11.11. Marco de medición CAPS medirá su desempeño en cinco resultados principales: 1. Capacidad. 2. Eficiencia. 3. Calidad. 4. Reutilización. 5. Aprendizaje institucional. ## 11.12. Resultado 1: Capacidad La capacidad representa la posibilidad del área para atender solicitudes con los recursos disponibles. ### Indicadores posibles - Número de cursos o solicitudes atendidos. - Cantidad de montajes simultáneos. - Tiempo promedio desde solicitud hasta entrega. - Distribución del trabajo entre perfiles. - Cantidad de necesidades cubiertas por patrones existentes. - Tiempo necesario para incorporar a una nueva persona. ### Interpretación Un aumento del volumen no demuestra por sí solo una mejora. Debe observarse junto con: - Calidad. - Retrabajo. - Carga de coordinación. - Sostenibilidad. - Dependencia de personas. CAPS busca ampliar capacidad sin deteriorar estos aspectos. ## 11.13. Resultado 2: Eficiencia La eficiencia representa la reducción del esfuerzo necesario para producir resultados adecuados. ### Indicadores posibles - Tiempo promedio de montaje por tipo de elemento. - Tiempo ahorrado mediante plantillas. - Tiempo dedicado a buscar información. - Tiempo utilizado en decisiones repetitivas. - Tiempo de revisión. - Cantidad de pasos manuales eliminados. - Reducción del tiempo de adaptación de componentes. ### Unidad de análisis Conviene medir actividades concretas: - Montar una lista de lecturas. - Crear una presentación de profesor. - Configurar un cronograma. - Integrar un recurso externo. - Construir una unidad estándar. Medir el tiempo total de un curso puede resultar menos útil porque los proyectos varían considerablemente. ## 11.14. Resultado 3: Calidad La calidad representa el cumplimiento consistente de los criterios definidos. ### Indicadores posibles - Correcciones posteriores a la revisión. - Errores funcionales. - Enlaces rotos. - Inconsistencias visuales. - Problemas de adaptabilidad. - Incumplimientos de accesibilidad. - Solicitudes de retrabajo. - Incidentes causados por componentes compartidos. - Percepción de claridad de profesores o estudiantes. ### Interpretación La ausencia de reportes no siempre significa ausencia de problemas. Por ello, conviene combinar: - Registros de correcciones. - Listas de comprobación. - Revisiones de muestra. - Retroalimentación cualitativa. ## 11.15. Resultado 4: Reutilización La reutilización representa la capacidad de aprovechar conocimiento ya validado. ### Indicadores posibles - Porcentaje de solicitudes que utilizan patrones existentes. - Número de aplicaciones por patrón. - Cantidad de cursos que usan plantillas. - Componentes utilizados en más de un proyecto. - Soluciones creadas desde cero. - Variaciones incorporadas. - Consultas al catálogo. - Patrones que nunca se utilizan. ### Interpretación Una tasa alta de reutilización no es siempre positiva si las soluciones se aplican fuera de contexto. La medición debe acompañarse de validación de calidad y pertinencia. ## 11.16. Resultado 5: Aprendizaje institucional El aprendizaje institucional representa la capacidad de convertir experiencia en mejoras del sistema. ### Indicadores posibles - Lecciones aprendidas registradas. - Lecciones que producen modificaciones. - Patrones mejorados por casos reales. - Nuevas variaciones documentadas. - Activos retirados por evidencia. - Decisiones arquitectónicas actualizadas. - Conocimiento transferido a nuevos integrantes. - Problemas recurrentes que disminuyen con el tiempo. ### Indicador clave No basta con contar lecciones. Debe observarse cuántas generaron una acción concreta: - Corrección. - Mejora. - Nuevo criterio. - Automatización. - Retiro. - Capacitación. - Modificación de un proceso. ## 11.17. Indicadores esenciales para la primera etapa Para evitar una medición excesiva, CAPS puede comenzar con seis indicadores: 1. **Uso de patrones:** porcentaje de necesidades recurrentes que utilizaron un patrón existente. 2. **Tiempo de montaje recurrente:** tiempo promedio para construir elementos priorizados. 3. **Retrabajo:** número de correcciones causadas por errores previsibles, inconsistencias o falta de criterios. 4. **Activos reutilizados:** cantidad de patrones, plantillas o componentes utilizados en más de un curso. 5. **Aprendizajes incorporados:** cantidad de lecciones que modificaron un activo o una decisión. 6. **Cobertura del catálogo:** porcentaje de necesidades frecuentes que cuentan con un patrón suficientemente documentado. Estos indicadores ofrecen una visión inicial de adopción, eficiencia, calidad y aprendizaje. ## 11.18. Indicadores de contexto Al interpretar los resultados, deben registrarse algunos factores de contexto: - Complejidad del curso. - Cantidad de contenidos. - Nivel de personalización. - Calidad de la información recibida. - Experiencia de las personas involucradas. - Número de revisiones académicas. - Restricciones técnicas. - Cambios posteriores a la solicitud inicial. - Uso de recursos externos. - Nivel de novedad de la solución. Estos factores ayudan a evitar comparaciones injustas entre proyectos muy diferentes. ## 11.19. Métricas que deben evitarse CAPS debe evitar indicadores que incentiven comportamientos contraproducentes. - **Cantidad total de componentes:** puede promover la creación innecesaria de activos. - **Cantidad de líneas de código:** no refleja valor, claridad ni reutilización. - **Número de patrones creados por persona:** puede convertir la contribución en una competencia cuantitativa. - **Velocidad sin calidad:** puede aumentar errores y mantenimiento futuro. - **Porcentaje de automatización como objetivo aislado:** puede promover automatizaciones innecesarias. - **Cantidad de documentación producida:** no demuestra que el conocimiento pueda encontrarse o utilizarse. - **Número de reuniones:** no representa colaboración efectiva. La medición debe concentrarse en resultados, no en actividad aparente. ## 11.20. Rendimiento sostenible CAPS busca mejorar el rendimiento sin producir costos ocultos. Una reducción de tiempo no será sostenible cuando dependa de: - Código difícil de mantener. - Sobrecarga de una persona experta. - Omisión de validaciones necesarias. - Copia de soluciones fuera de contexto. - Automatización sin control. - Acumulación de deuda técnica. - Pérdida de accesibilidad. - Aumento de errores posteriores. Por ello, toda mejora de eficiencia debe contrastarse con: - Calidad. - Mantenimiento. - Riesgo. - Reutilización. - Coordinación. - Satisfacción de quienes utilizan el resultado. Esta idea retoma la perspectiva de Brooks: una aparente aceleración puede aumentar la complejidad y retrasar el sistema posteriormente. ## 11.21. Medición del costo de coordinación CAPS busca reducir el esfuerzo necesario para coordinar múltiples perfiles. Puede observarse mediante: - Cantidad de consultas necesarias para utilizar un componente. - Número de revisiones por falta de información. - Tiempo dedicado a explicar soluciones existentes. - Dependencia de reuniones. - Bloqueos por ausencia de una persona. - Correcciones por interpretaciones diferentes. - Tiempo de incorporación de nuevos participantes. La reducción del costo de coordinación es uno de los beneficios más estratégicos de CAPS, aunque no siempre sea visible en el producto final. ## 11.22. Medición de inteligencia artificial El uso de IA debe evaluarse por su contribución al proceso, no por la cantidad de herramientas utilizadas. ### Indicadores posibles - Tiempo ahorrado en tareas específicas. - Porcentaje de salidas aceptadas con ajustes menores. - Cantidad de correcciones necesarias. - Frecuencia de errores repetidos. - Cumplimiento de patrones y criterios. - Número de personas que pueden utilizar el prompt. - Estabilidad de resultados. - Tareas que continúan requiriendo revisión especializada. - Incidentes o riesgos identificados. ### Pregunta fundamental **¿La IA está reduciendo trabajo repetitivo sin trasladar una carga mayor a la revisión, corrección o mantenimiento?** ## 11.23. Tablero mínimo de CAPS ### Adopción - Cursos que utilizaron CAPS. - Patrones más utilizados. - Usuarios o perfiles participantes. ### Producción - Tiempo de montaje de elementos priorizados. - Solicitudes atendidas. - Reutilización de activos. ### Calidad - Correcciones. - Incidentes. - Retrabajo. - Activos que requieren actualización. ### Evolución - Patrones candidatos. - Activos en prueba. - Aprendizajes incorporados. - Activos validados o retirados. El tablero debe permitir comprender rápidamente si CAPS está siendo utilizado, si produce beneficios y qué requiere atención. ## 11.24. Ciclo de medición La medición puede seguir un ciclo breve: 1. Definir qué capacidad se quiere mejorar. 2. Registrar una línea base. 3. Aplicar patrones o mejoras. 4. Medir nuevamente. 5. Comparar resultados. 6. Interpretar el contexto. 7. Decidir qué mantener, modificar o retirar. 8. Incorporar el aprendizaje a CAPS. No todos los indicadores deben medirse continuamente. La frecuencia dependerá del volumen de producción y de los ciclos de revisión estratégica. ## 11.25. Evaluación cualitativa Algunos beneficios no pueden comprenderse únicamente mediante cifras. CAPS debe recoger observaciones de: - Montadores. - Diseñadores. - Revisores. - Profesores. - Coordinadores. - Áreas solicitantes. - Estudiantes, cuando resulte pertinente. ### Preguntas cualitativas sugeridas - ¿Fue fácil encontrar una solución? - ¿La ficha permitió utilizarla con autonomía? - ¿Qué información hizo falta? - ¿Qué parte generó mayor dificultad? - ¿La solución redujo decisiones? - ¿El resultado fue consistente con otros cursos? - ¿Qué debería mejorar? - ¿Volvería a utilizarse? - ¿Qué conocimiento habría sido útil antes? La evidencia cualitativa ayuda a explicar los indicadores y a detectar problemas que todavía no aparecen en los datos. ## 11.26. Revisión de madurez CAPS puede revisar su madurez mediante una sesión estructurada y breve. ### Participantes - Orientación estratégica. - Responsable de arquitectura. - Curaduría. - Representantes de producción. - Especialistas relevantes. ### Preguntas de revisión - ¿Qué capacidades se consolidaron? - ¿Qué continúa dependiendo de personas específicas? - ¿Qué patrones producen mayor valor? - ¿Dónde existe más retrabajo? - ¿Qué activos no se utilizan? - ¿Qué tareas están listas para automatizarse? - ¿Qué complejidad innecesaria hemos introducido? - ¿Cuál es la siguiente capacidad prioritaria? ### Resultado La revisión debe producir: - Nivel aproximado por dimensión. - Evidencias. - Brechas principales. - Una o dos prioridades de mejora. - Activos o prácticas que deben retirarse. - Decisiones que requieren seguimiento. ## 11.27. Criterios para avanzar de nivel ### De inicial a organizado Se requiere: - Lenguaje básico común. - Patrones prioritarios identificados. - Catálogo inicial. - Estados visibles. - Responsables. - Primeros casos reales. ### De organizado a integrado Se requiere: - Uso habitual. - Incorporación al flujo de producción. - Reutilización verificable. - Validación proporcional al riesgo. - Aprendizajes que actualizan activos. - Indicadores básicos. - Responsabilidad distribuida. ### De integrado a adaptativo Se requiere: - Datos que orientan decisiones. - Automatización de tareas estables. - Uso transversal. - Gestión sistemática de cambios. - Capacidad de adaptación a nuevas necesidades. - Aprendizaje consolidado entre proyectos. - Menor dependencia de conocimiento individual. No es necesario que todas las dimensiones avancen simultáneamente. ## 11.28. Relación con los pilares - **Conocimiento:** de archivos dispersos a una red de activos consultable y aprendiente. - **Producción:** de procesos dependientes de personas a flujos apoyados por patrones y evidencia. - **Pedagogía:** de decisiones implícitas a criterios claros vinculados con la experiencia de aprendizaje. - **Experiencia y comunicación visual:** de soluciones particulares a un lenguaje visual coherente y adaptable. - **Técnica y componentes:** de fragmentos de código a implementaciones versionadas, compatibles y mantenibles. - **Automatización e inteligencia artificial:** de usos improvisados a flujos asistidos por conocimiento institucional. - **Gobernanza transversal:** de decisiones informales a responsabilidad distribuida y evolución controlada. ## 11.29. Riesgos del modelo de madurez ### Convertir el nivel en un objetivo burocrático El equipo puede producir documentación solo para aparentar avance. **Respuesta:** exigir evidencia de uso y resultados. ### Comparar personas o áreas Puede generar resistencia y ocultamiento de problemas. **Respuesta:** evaluar capacidades del sistema, no desempeño individual. ### Medir demasiado pronto Puede dedicarse más esfuerzo a medir que a construir valor. **Respuesta:** comenzar con línea base e indicadores mínimos. ### Buscar el nivel más alto en todo Puede introducir complejidad innecesaria. **Respuesta:** desarrollar la madurez requerida por cada necesidad. ### Ignorar el contexto Las variaciones entre proyectos pueden producir conclusiones incorrectas. **Respuesta:** registrar factores de complejidad y combinar datos cuantitativos y cualitativos. ### Premiar velocidad aislada Puede aumentar retrabajo y deuda técnica. **Respuesta:** evaluar eficiencia junto con calidad y mantenimiento. ## 11.30. Criterios de éxito del modelo El modelo de madurez y medición será útil cuando: - Permita explicar claramente la situación actual. - Muestre avances sin depender de percepciones. - Ayude a priorizar capacidades. - Evidencie beneficios para otras áreas. - Detecte dependencias y riesgos. - Permita reconocer cuándo una práctica está lista para automatizarse. - Evite medir actividad sin valor. - Facilite conversaciones estratégicas con la dirección. - Oriente decisiones sobre recursos. - Mantenga la medición proporcional a la capacidad real del equipo. ## 11.31. Síntesis del modelo CAPS evoluciona mediante cuatro niveles: 1. **Inicial:** el conocimiento existe, pero permanece disperso. 2. **Organizado:** los activos prioritarios están documentados y pueden consultarse. 3. **Integrado:** CAPS forma parte habitual de la producción. 4. **Adaptativo:** el sistema utiliza evidencia, aprendizaje y automatización para evolucionar. Su desempeño se observará principalmente mediante: - Capacidad. - Eficiencia. - Calidad. - Reutilización. - Aprendizaje institucional. La idea central puede expresarse así: > **CAPS madura cuando el conocimiento deja de ser solamente accesible y comienza a modificar de manera verificable cómo el área produce, aprende y responde a nuevas necesidades.** El objetivo final no es alcanzar una categoría de madurez. Es construir la capacidad necesaria para escalar la producción sin perder claridad, calidad ni integridad conceptual. --- # 12. Hoja de ruta de implementación de CAPS ## 12.1. Propósito de la hoja de ruta La hoja de ruta establece cómo pasar del repositorio actual de soluciones y fragmentos técnicos a una capacidad institucional integrada para la producción de cursos. Su finalidad es ordenar el esfuerzo, reducir incertidumbre y evitar que CAPS se convierta en un proyecto demasiado amplio antes de demostrar utilidad. La implementación debe seguir una lógica progresiva: > **Comprender lo existente, organizar lo prioritario, probarlo en producción, consolidar el modelo y automatizar únicamente aquello que haya demostrado estabilidad.** La hoja de ruta no pretende definir desde el inicio todas las fechas, herramientas o activos futuros. Presenta una secuencia de capacidades que podrá ajustarse según las necesidades, recursos y aprendizajes del área. ## 12.2. Principios de implementación ### Comenzar con problemas reales Los primeros patrones deben surgir de necesidades frecuentes observadas en los cursos, no de una clasificación teórica completa. ### Construir el mínimo sistema útil La primera versión debe contener únicamente los elementos necesarios para consultar, aplicar y mejorar algunos patrones prioritarios. ### Probar antes de ampliar Las fichas, plantillas, componentes y procesos deben utilizarse en proyectos reales antes de extenderse a todo el área. ### Migrar progresivamente No es necesario convertir todo el repositorio actual de manera simultánea. Deben priorizarse los activos con mayor frecuencia, impacto o riesgo. ### Integrar la documentación al trabajo La captura de conocimiento debe ocurrir dentro del proceso normal de producción, evitando crear una operación paralela. ### Medir pocos resultados relevantes La primera etapa debe concentrarse en reutilización, tiempo de montaje, retrabajo, adopción y aprendizaje incorporado. ### Automatizar después de estabilizar La inteligencia artificial y las automatizaciones deben operar sobre patrones suficientemente comprendidos y validados. ### Mantener reversibilidad Las nuevas prácticas deben poder ajustarse o retirarse sin comprometer toda la producción. ## 12.3. Estructura de la hoja de ruta La implementación de CAPS se organiza en cinco fases: 1. Alineación y diagnóstico. 2. Catálogo mínimo viable. 3. Pilotaje en producción. 4. Consolidación e integración. 5. Automatización y escalamiento. Cada fase produce una capacidad concreta y prepara las condiciones para la siguiente. No es necesario completar absolutamente todos los elementos de una fase antes de iniciar actividades exploratorias de la posterior. Sin embargo, no debe avanzarse hacia una automatización amplia sin contar con conocimiento organizado y evidencia de aplicación. ## 12.4. Fase 1: Alineación y diagnóstico ### Propósito Construir una comprensión compartida sobre el problema, el alcance y los activos existentes. Esta fase evita que CAPS comience únicamente como una reorganización de documentos o como un proyecto de desarrollo técnico. ### Objetivos - Socializar la visión y el manifiesto. - Confirmar el alcance del framework. - Identificar necesidades recurrentes. - Reconocer el conocimiento ya construido. - Detectar dependencias, duplicaciones y riesgos. - Seleccionar los primeros patrones. - Asignar responsabilidades iniciales. - Establecer una línea base mínima. ### Actividades principales #### Presentación estratégica Compartir con las personas involucradas: - El problema que CAPS busca resolver. - Su definición institucional. - La diferencia entre patrón y componente. - Los principios arquitectónicos. - Los beneficios esperados. - El carácter progresivo de la iniciativa. #### Mapeo de participantes Identificar: - Quiénes producen cursos. - Quiénes diseñan contenidos y elementos visuales. - Quiénes realizan montaje técnico. - Quiénes validan. - Quiénes mantienen información o repositorios. - Quiénes utilizan herramientas de IA. - Quiénes toman decisiones de alcance y prioridad. #### Inventario inicial Revisar: - Repositorios existentes. - Páginas de Notion. - Fragmentos HTML. - Plantillas. - Prompts. - Guías. - Cursos que contienen soluciones reutilizables. - Lecciones no documentadas. - Componentes frecuentes. #### Identificación de necesidades recurrentes Agrupar problemas como: - Presentación de lecturas. - Organización de unidades. - Presentación del profesor. - Cronogramas. - Navegación. - Orientaciones. - Recursos externos. - Contenido interactivo. - Comunicación de información importante. #### Selección de prioridades Escoger entre cinco y diez necesidades que cumplan varias de estas condiciones: - Aparecen con frecuencia. - Consumen tiempo. - Generan retrabajo. - Ya cuentan con soluciones parciales. - Pueden beneficiar distintos cursos. - Son suficientemente estables para documentarse. #### Línea base Registrar de forma aproximada: - Tiempo actual de montaje. - Cantidad de correcciones. - Soluciones creadas desde cero. - Dependencias de personas. - Uso de componentes existentes. - Dificultades para localizar información. ### Entregables - Documento fundacional de CAPS. - Mapa inicial de participantes. - Inventario de activos. - Lista priorizada de necesidades. - Selección de patrones iniciales. - Responsables provisionales. - Línea base mínima. ### Criterio de cierre La fase se considera suficientemente completa cuando el equipo puede responder: - Qué problema resolverá CAPS. - Qué conocimiento ya existe. - Qué se trabajará primero. - Quién coordinará la arquitectura y el catálogo. - En qué proyectos se realizará la prueba. ## 12.5. Fase 2: Catálogo mínimo viable ### Propósito Construir una primera versión utilizable del catálogo con un número limitado de patrones prioritarios. El objetivo no es tener un sistema completo. Es comprobar que las personas pueden encontrar, comprender y reutilizar conocimiento de manera más eficiente. ### Objetivos - Diseñar la estructura mínima del catálogo. - Migrar los activos prioritarios. - Crear fichas de patrones. - Relacionar patrones, componentes y casos. - Establecer estados y responsables. - Preparar plantillas iniciales. - Definir criterios mínimos de validación. ### Actividades principales #### Configuración de la herramienta Preparar en Notion u otra herramienta: - Base de patrones. - Base de componentes. - Base de casos. - Estados. - Responsables. - Relaciones. - Vistas por necesidad y estado. La herramienta debe mantenerse sencilla y modificable. #### Construcción de fichas Documentar para cada patrón: - Problema. - Propósito. - Contexto. - Criterios. - Implementaciones disponibles. - Restricciones. - Forma de validación. - Caso inicial. #### Revisión de componentes Para los componentes existentes: - Detectar duplicaciones. - Revisar compatibilidad. - Identificar código obsoleto. - Relacionarlos con patrones. - Determinar elementos editables. - Clasificarlos por estado. #### Creación de plantillas Desarrollar únicamente las plantillas necesarias para los patrones seleccionados. #### Selección de casos piloto Elegir cursos o solicitudes reales que permitan probar: - Distintos perfiles. - Diferentes tipos de contenido. - Variaciones razonables. - Problemas de montaje frecuentes. #### Preparación de orientación básica Crear una guía breve que explique: - Cómo buscar. - Cómo interpretar una ficha. - Cómo aplicar un patrón. - Cómo informar un problema. - Cómo registrar un aprendizaje. ### Entregables - Catálogo mínimo viable. - Cinco a diez patrones documentados. - Componentes prioritarios clasificados. - Plantillas iniciales. - Casos seleccionados para prueba. - Guía breve de uso. - Criterios de validación. ### Criterio de cierre La fase se considera suficientemente completa cuando una persona distinta al autor puede localizar un patrón, comprenderlo y utilizar una implementación sin depender de una explicación extensa. ## 12.6. Fase 3: Pilotaje en producción ### Propósito Comprobar el funcionamiento de CAPS dentro de proyectos reales. Esta fase debe revelar si el framework reduce trabajo o, por el contrario, introduce pasos innecesarios. ### Objetivos - Integrar CAPS al montaje de cursos piloto. - Validar patrones y plantillas. - Medir beneficios iniciales. - Detectar vacíos de información. - Ajustar el modelo operativo. - Documentar aprendizajes. - Evaluar la experiencia de los participantes. ### Actividades principales #### Selección de patrones Al inicio de cada curso piloto, identificar: - Qué necesidades están cubiertas. - Qué patrones se utilizarán. - Qué activos requieren adaptación. - Qué necesidades todavía no tienen solución. #### Aplicación controlada Los participantes utilizan las fichas, plantillas y componentes dentro de la producción normal. #### Registro de observaciones Documentar brevemente: - Dificultades para encontrar activos. - Información faltante. - Adaptaciones. - Errores. - Correcciones. - Beneficios percibidos. - Tareas repetitivas. #### Validación Comprobar: - Funcionamiento. - Claridad. - Coherencia. - Accesibilidad. - Compatibilidad. - Mantenimiento. - Adecuación pedagógica. #### Medición Comparar con la línea base: - Tiempo de montaje. - Número de correcciones. - Cantidad de consultas. - Activos reutilizados. - Soluciones creadas desde cero. - Percepción de autonomía. #### Cierre del piloto Determinar para cada activo: - Si se valida. - Si continúa en prueba. - Si requiere modificación. - Si debe consolidarse con otro. - Si debe retirarse. ### Entregables - Cursos piloto montados. - Casos de aplicación. - Resultados de medición. - Patrones corregidos. - Variaciones identificadas. - Lecciones aprendidas. - Recomendaciones para la siguiente fase. ### Criterio de cierre La fase se considera exitosa cuando existe evidencia de que algunos activos: - Se reutilizaron correctamente. - Redujeron decisiones o tiempo. - Mantuvieron o mejoraron la calidad. - Pudieron ser utilizados por diferentes personas. - Generaron aprendizajes incorporables al sistema. ## 12.7. Fase 4: Consolidación e integración ### Propósito Convertir CAPS en parte habitual de la producción, superando el uso limitado a proyectos piloto. ### Objetivos - Integrar la consulta del catálogo al inicio de las solicitudes. - Ampliar patrones según necesidades comprobadas. - Distribuir responsabilidades. - Mejorar la gobernanza. - Fortalecer la incorporación de nuevos participantes. - Establecer medición regular. - Conectar CAPS con los procesos del área. ### Actividades principales #### Integración al flujo de producción Incorporar preguntas como: - ¿Qué patrón aplica? - ¿Qué plantilla se utilizará? - ¿Existe una implementación validada? - ¿La solicitud requiere una excepción? - ¿Qué aprendizaje debe regresar a CAPS? Estas preguntas pueden incorporarse a los formatos o conversaciones ya existentes. #### Ampliación controlada Agregar nuevos patrones según: - Frecuencia. - Impacto. - Retrabajo. - Riesgo. - Demanda de las áreas. #### Distribución de responsabilidades Separar progresivamente: - Arquitectura. - Curaduría. - Validación especializada. - Mantenimiento técnico. - Gestión de prompts. #### Formación e incorporación Preparar: - Recorrido inicial. - Casos demostrativos. - Guías de aplicación. - Ejercicios prácticos. - Acompañamiento en primeros usos. #### Revisión del catálogo Consolidar: - Nombres. - Versiones. - Estados. - Relaciones. - Responsables. - Activos retirados. #### Comunicación de resultados Presentar a la dirección y otras áreas: - Casos de éxito. - Tiempo reducido. - Retrabajo evitado. - Capacidad ampliada. - Próximas prioridades. ### Entregables - CAPS integrado al proceso de producción. - Catálogo ampliado mediante evidencia. - Responsabilidades distribuidas. - Material de incorporación. - Tablero básico. - Ciclo periódico de revisión. - Informe de beneficios iniciales. ### Criterio de cierre La fase se considera consolidada cuando la consulta y aplicación de CAPS deja de depender exclusivamente de sus promotores y se convierte en una práctica normal de diferentes participantes. ## 12.8. Fase 5: Automatización y escalamiento ### Propósito Utilizar automatización e inteligencia artificial para ampliar la capacidad del área sobre una base de conocimiento estable. La automatización no debe emplearse para ocultar desorden o falta de claridad. Debe reducir trabajo repetitivo dentro de procesos ya comprendidos. ### Objetivos - Identificar tareas estables y repetitivas. - Convertir patrones en instrucciones estructuradas. - Diseñar prompts validados. - Automatizar generación y adaptación controlada. - Facilitar la consulta del catálogo. - Apoyar validaciones básicas. - Escalar CAPS a más tipos de cursos o equipos. ### Actividades principales #### Identificación de oportunidades Evaluar tareas como: - Estructuración de referencias. - Preparación de listas. - Adaptación de contenido a plantillas. - Generación inicial de HTML validado. - Verificación de campos. - Clasificación de recursos. - Detección de inconsistencias. - Generación de fichas preliminares. - Búsqueda de patrones relacionados. #### Priorización de automatizaciones Seleccionar tareas que sean: - Frecuentes. - Estables. - Comprensibles. - Verificables. - De bajo o medio riesgo. - Costosas manualmente. - Repetitivas. #### Estructuración del conocimiento Convertir patrones en información que la IA pueda consultar: - Entradas. - Reglas. - Restricciones. - Ejemplos. - Formatos de salida. - Criterios de revisión. #### Pruebas y control Evaluar: - Estabilidad. - Calidad de salidas. - Tiempo realmente ahorrado. - Correcciones necesarias. - Riesgos. - Mantenimiento. - Dependencia de herramientas específicas. #### Integración progresiva Incorporar automatizaciones en pasos controlados, conservando: - Revisión humana. - Registro de versiones. - Posibilidad de reversión. - Alternativa manual. - Responsables. ### Entregables - Biblioteca de prompts validados. - Automatizaciones priorizadas. - Flujos asistidos. - Criterios de revisión. - Evidencia de ahorro. - Documentación de riesgos. - Plan de escalamiento. ### Criterio de madurez La fase se considera madura cuando la automatización reduce trabajo real sin aumentar de manera desproporcionada la corrección, el riesgo o el mantenimiento. ## 12.9. Secuencia de capacidades ### Primero: lenguaje común El equipo comprende qué es CAPS, qué es un patrón y qué problema busca resolver. ### Después: conocimiento organizado Los activos prioritarios pueden encontrarse y utilizarse. ### Luego: aplicación comprobada Los patrones demuestran utilidad en cursos reales. ### Después: integración organizacional CAPS forma parte del flujo habitual y no depende de un grupo reducido. ### Finalmente: automatización responsable La tecnología amplía una capacidad ya comprendida y validada. Esta secuencia evita comenzar por la herramienta antes de definir el sistema. ## 12.10. Primer conjunto sugerido de patrones A partir de los activos existentes, el catálogo inicial podría trabajar sobre: 1. Organización de lecturas requeridas y recursos complementarios. 2. Presentación del profesor o equipo docente. 3. Comunicación de cronogramas y fechas. 4. Orientación y bienvenida de una unidad. 5. Navegación de retorno. 6. Presentación de información extensa mediante tarjetas. 7. Integración de recursos externos o embebidos. 8. Comunicación de medios de interacción. 9. Presentación de documentos institucionales. 10. Organización visual de unidades o semanas. Estos patrones ofrecen una base práctica porque ya cuentan con ejemplos y responden a necesidades observables. La selección definitiva deberá validarse con las personas que participan en la producción. ## 12.11. Backlog inicial ### Fundamentos - Validar el documento fundacional. - Confirmar vocabulario. - Designar responsable de arquitectura. - Confirmar alcance. ### Diagnóstico - Inventariar activos. - Agrupar por necesidad. - Identificar duplicados. - Revisar vigencia. - Registrar línea base. ### Catálogo - Configurar bases. - Crear vistas. - Diseñar fichas. - Migrar patrones prioritarios. - Relacionar componentes. ### Validación - Definir criterios mínimos. - Seleccionar cursos piloto. - Probar patrones. - Documentar casos. - Ajustar activos. ### Adopción - Preparar guía. - Socializar CAPS. - Acompañar primeros usos. - Recoger retroalimentación. - Distribuir responsabilidades. ### Medición - Medir uso. - Medir tiempos. - Registrar retrabajo. - Analizar aprendizajes. - Comunicar beneficios. ### IA y automatización - Identificar tareas. - Diseñar prompts. - Probar salidas. - Documentar límites. - Validar ahorro real. El backlog debe priorizarse periódicamente y no ejecutarse como una lista cerrada. ## 12.12. Criterios de priorización de patrones Los primeros patrones deben seleccionarse según: - **Recurrencia:** aparecen en numerosos cursos. - **Esfuerzo:** consumen una cantidad relevante de tiempo. - **Variabilidad:** se resuelven de maneras diferentes y producen inconsistencias. - **Retrabajo:** generan correcciones frecuentes. - **Madurez:** existen ejemplos suficientes para identificar una solución común. - **Impacto:** afectan una parte visible o importante de la experiencia. - **Viabilidad:** pueden documentarse y probarse sin depender de desarrollos extensos. No deben priorizarse únicamente por su novedad o atractivo visual. ## 12.13. Alcance de la primera versión La primera versión de CAPS no necesita incluir: - Todos los tipos de cursos. - Todos los componentes existentes. - Una automatización completa. - Un sistema de software propio. - Un modelo sofisticado de permisos. - Integración automática con Moodle. - Indicadores exhaustivos. - Gobernanza formal de gran escala. - Documentación detallada de cada excepción histórica. La primera versión debe demostrar tres capacidades: 1. Encontrar una solución. 2. Aplicarla correctamente. 3. Incorporar el aprendizaje resultante. Si estas capacidades funcionan, CAPS contará con una base real para crecer. ## 12.14. Estrategia de adopción La adopción no debe depender únicamente de presentar el framework en una reunión. Debe demostrar utilidad dentro del trabajo. ### Acciones recomendadas - Construir patrones junto con sus usuarios. - Comenzar por problemas que producen frustración o retrabajo. - Mostrar comparaciones antes y después. - Permitir contribuciones tempranas. - Evitar documentación extensa. - Ofrecer ejemplos funcionales. - Corregir rápidamente dificultades de uso. - Reconocer las contribuciones. - Mantener visibles los resultados. - Integrar CAPS a herramientas conocidas. ### Mensaje de adopción CAPS debe presentarse como: - Una forma de evitar repetir trabajo. - Un mecanismo para conservar soluciones útiles. - Un lenguaje común. - Un apoyo para trabajar con mayor autonomía. - Una base para utilizar IA con mayor seguridad. - Una capacidad del equipo, no un control adicional. ## 12.15. Gestión del cambio La implementación de CAPS modifica hábitos, decisiones y relaciones entre perfiles. Algunas resistencias pueden originarse en: - Temor a perder autonomía. - Percepción de mayor documentación. - Dudas sobre la utilidad. - Preferencia por soluciones personales. - Falta de tiempo. - Incertidumbre sobre responsabilidades. - Experiencias anteriores con repositorios abandonados. ### Respuestas recomendadas - Involucrar a los usuarios en el diseño. - Comenzar con activos de utilidad evidente. - Mantener fichas breves. - Mostrar beneficios concretos. - Permitir experimentación. - Diferenciar criterios obligatorios y adaptables. - Evitar convertir CAPS en un sistema de vigilancia. - Garantizar mantenimiento y curaduría. La confianza se construirá mediante utilidad sostenida, no solamente mediante comunicación. ## 12.16. Dependencias críticas ### Patrocinio estratégico Se necesita respaldo para priorizar tiempo, facilitar colaboración, resolver decisiones transversales y reconocer CAPS como iniciativa del área. ### Responsable de arquitectura Debe existir una persona o función que conserve coherencia y coordine la evolución. ### Participación interdisciplinaria Los patrones no pueden construirse únicamente desde la perspectiva técnica. ### Casos reales CAPS necesita cursos reales para aprender y validar. ### Curaduría Los activos requieren mantenimiento y organización. ### Acceso a información Se necesita revisar repositorios, cursos y prácticas existentes. ### Capacidad mínima de medición Debe ser posible registrar algunos tiempos, usos y correcciones. Sin estas condiciones, CAPS corre el riesgo de convertirse nuevamente en documentación sin integración operativa. ## 12.17. Riesgos de implementación ### Intentar construir todo desde el inicio Puede paralizar la iniciativa. **Respuesta:** comenzar con un catálogo mínimo y pocos patrones. ### Priorizar la herramienta Puede dedicarse más esfuerzo a configurar Notion que a estructurar conocimiento útil. **Respuesta:** definir fichas y relaciones antes de sofisticar la plataforma. ### Migrar sin curar Puede trasladarse el desorden anterior a una nueva herramienta. **Respuesta:** revisar propósito, vigencia y relaciones de cada activo prioritario. ### Falta de uso real El catálogo puede verse bien, pero no modificar la producción. **Respuesta:** vincular cada fase con cursos piloto. ### Dependencia de una persona CAPS puede detenerse si su promotor cambia de función. **Respuesta:** documentar, distribuir responsabilidades y formar contribuidores. ### Automatización prematura Puede multiplicar errores y variaciones. **Respuesta:** automatizar solo patrones validados. ### Medición excesiva Puede generar rechazo y trabajo administrativo. **Respuesta:** utilizar pocos indicadores vinculados con decisiones. ### Pérdida de apoyo La iniciativa puede percibirse como secundaria si no comunica beneficios. **Respuesta:** presentar resultados tempranos y casos concretos. ## 12.18. Decisiones de continuidad Al finalizar cada fase, CAPS debe responder: - ¿Qué valor se produjo? - ¿Qué dificultades aparecieron? - ¿Qué debe simplificarse? - ¿Qué activos deben validarse o retirarse? - ¿Qué capacidad resulta prioritaria ahora? - ¿Existen condiciones para avanzar? - ¿Qué no debe construirse todavía? Estas decisiones permiten corregir la hoja de ruta y evitar que el plan se convierta en una obligación rígida. ## 12.19. Resultados esperados por horizonte ### Horizonte inmediato: hacer visible el conocimiento Resultados: - Fundamentos aprobados. - Inventario. - Patrones iniciales. - Catálogo mínimo. - Responsables. ### Horizonte de consolidación: convertir conocimiento en operación Resultados: - Patrones utilizados. - Plantillas validadas. - Aprendizajes incorporados. - Medición básica. - Adopción por diferentes perfiles. - Reducción inicial de tiempos o retrabajo. ### Horizonte de expansión: convertir conocimiento en capacidad escalable Resultados: - Integración al flujo. - Automatizaciones. - Mayor cobertura. - Responsabilidades distribuidas. - Decisiones basadas en evidencia. - Capacidad para atender más solicitudes con coherencia. Los horizontes deben traducirse posteriormente a fechas según la disponibilidad real del área. ## 12.20. Hoja de ruta mínima para presentar en reunión La propuesta puede explicarse mediante cinco movimientos: 1. **Reconocer:** identificar el conocimiento y las soluciones que ya existen. 2. **Organizar:** convertir las soluciones prioritarias en patrones y activos relacionados. 3. **Probar:** aplicar CAPS en cursos reales y medir su utilidad. 4. **Integrar:** incorporar los patrones al trabajo habitual y distribuir responsabilidades. 5. **Escalar:** automatizar tareas estables y ampliar la cobertura. Esta formulación permite comunicar la estrategia sin entrar inicialmente en todos los detalles del framework. ## 12.21. Criterios de éxito de la implementación La hoja de ruta será exitosa cuando: - CAPS produzca valor desde sus primeras versiones. - El equipo pueda utilizarlo sin depender exclusivamente de sus creadores. - Los patrones prioritarios reduzcan decisiones repetitivas. - El catálogo permanezca simple y consultable. - Los cursos reales mejoren el sistema. - La medición evidencie beneficios. - La gobernanza no retrase la operación. - Las responsabilidades puedan distribuirse. - La IA se incorpore sobre conocimiento validado. - El framework pueda adaptarse sin perder su propósito. ## 12.22. Síntesis de la hoja de ruta La implementación de CAPS seguirá una progresión deliberada: > **Alinear → inventariar → organizar → probar → integrar → automatizar → escalar.** La secuencia protege al proyecto de dos riesgos: - Construir una arquitectura demasiado compleja antes de demostrar valor. - Buscar velocidad mediante herramientas sin contar con conocimiento organizado. La hoja de ruta responde a la fundamentación de Brooks: la capacidad no aumentará simplemente agregando personas, código o inteligencia artificial. Aumentará cuando el área reduzca la complejidad de coordinación y construya una arquitectura común que permita reutilizar el conocimiento. CAPS debe comenzar pequeño, demostrar utilidad y crecer mediante evidencia. --- # 13. Visión futura y propuesta de valor institucional de CAPS ## 13.1. Propósito del capítulo CAPS nace para responder a una necesidad inmediata: organizar el conocimiento de producción, reducir el trabajo repetitivo y mejorar la capacidad del área para atender una mayor cantidad de solicitudes de cursos. Sin embargo, su valor estratégico no se limita a resolver los problemas actuales. A medida que CAPS madure, deberá convertirse en una infraestructura institucional de conocimiento que permita diseñar, ensamblar y evolucionar cursos con mayor coherencia, autonomía y capacidad de adaptación. La visión futura no describe una plataforma tecnológica completamente definida ni promete una automatización total. Establece el estado organizacional al que se aspira y los principios que deberán conservarse durante su evolución. ## 13.2. Visión de CAPS La visión de CAPS es: > **Consolidar una capacidad institucional para producir y evolucionar cursos mediante conocimiento estructurado, patrones compartidos y automatización responsable, permitiendo que el área responda a una demanda creciente sin perder calidad, coherencia ni capacidad de aprendizaje.** En este estado futuro: - El conocimiento esencial de producción no permanece disperso. - Las necesidades recurrentes cuentan con patrones comprensibles. - Los componentes técnicos se encuentran vinculados con propósitos concretos. - Diferentes perfiles pueden contribuir con autonomía. - Las decisiones transversales conservan integridad conceptual. - Los nuevos integrantes pueden incorporarse con mayor rapidez. - Las herramientas de inteligencia artificial trabajan sobre criterios institucionales. - Los aprendizajes de cada proyecto fortalecen la producción futura. - El área puede demostrar su contribución mediante resultados verificables. CAPS deberá permitir que el crecimiento del volumen de trabajo no produzca un aumento equivalente en complejidad, coordinación o retrabajo. ## 13.3. Misión de CAPS La misión de CAPS es: > **Capturar, organizar, validar y reutilizar el conocimiento generado durante la producción de cursos, articulando decisiones pedagógicas, visuales, técnicas y operativas dentro de una arquitectura común.** Esta misión se concreta mediante cuatro responsabilidades permanentes: - **Conservar:** evitar que las decisiones, soluciones y aprendizajes dependan únicamente de la memoria individual. - **Orientar:** proporcionar criterios para seleccionar y adaptar soluciones de montaje. - **Facilitar:** reducir decisiones repetitivas y ofrecer caminos claros para la producción. - **Evolucionar:** transformar la experiencia de los cursos reales en mejoras del sistema. ## 13.4. Aspiración institucional CAPS aspira a convertir el área de producción en una organización que aprende sistemáticamente de su trabajo. Esto significa que cada solicitud de curso debe ser comprendida no solo como una entrega, sino como una fuente potencial de: - Conocimiento reutilizable. - Nuevos patrones. - Mejores criterios. - Componentes más sólidos. - Variaciones documentadas. - Automatizaciones responsables. - Evidencia para tomar decisiones. - Capacidades transferibles a otros proyectos. La producción deja así de ser exclusivamente una secuencia de encargos y se convierte en un proceso acumulativo de fortalecimiento institucional. El resultado esperado no es únicamente hacer más cursos. Es mejorar de manera progresiva la capacidad con la que se construye cada uno. ## 13.5. Propuesta de valor institucional La propuesta de valor de CAPS puede formularse de la siguiente manera: > **CAPS permite que la institución atienda una mayor demanda de producción de cursos mediante soluciones coherentes y reutilizables, transformando la experiencia del equipo en conocimiento organizacional y reduciendo el costo de coordinación, montaje y aprendizaje.** Esta propuesta de valor se expresa en seis dimensiones. ### 13.5.1. Valor para la producción CAPS permite: - Disminuir decisiones repetitivas. - Encontrar soluciones con mayor rapidez. - Reutilizar activos validados. - Reducir montajes construidos completamente desde cero. - Mejorar la previsibilidad del trabajo. - Identificar dependencias antes de iniciar. - Disminuir correcciones evitables. - Facilitar la atención simultánea de diferentes solicitudes. El valor no proviene únicamente de tener componentes disponibles. Proviene de conocer el propósito, las condiciones y los límites de esos componentes. ### 13.5.2. Valor para la calidad CAPS permite: - Mantener criterios compartidos. - Conservar coherencia entre cursos. - Mejorar la claridad de la información. - Proteger la accesibilidad. - Reducir errores técnicos. - Facilitar revisiones proporcionales al riesgo. - Evitar variaciones arbitrarias. - Mantener trazabilidad sobre decisiones relevantes. La calidad deja de depender exclusivamente de revisiones posteriores y comienza a incorporarse desde la selección de los patrones. ### 13.5.3. Valor para el conocimiento institucional CAPS permite: - Conservar decisiones y aprendizajes. - Disminuir la dependencia de expertos individuales. - Facilitar la transferencia de conocimiento. - Preservar la historia de las soluciones. - Identificar activos vigentes y retirados. - Convertir errores en criterios preventivos. - Aprovechar experiencias de distintos cursos. - Mantener una memoria activa de producción. El conocimiento deja de ser un subproducto informal y se convierte en una infraestructura de trabajo. ### 13.5.4. Valor para la colaboración CAPS permite: - Crear un lenguaje común entre disciplinas. - Aclarar qué aporta cada perfil. - Definir interfaces entre pedagogía, diseño, producción y tecnología. - Facilitar contribuciones sin exigir que todas las personas dominen el sistema completo. - Distribuir responsabilidades. - Reducir consultas y reuniones innecesarias. - Resolver desacuerdos mediante criterios. - Conservar una visión arquitectónica común. La colaboración deja de depender únicamente de la coordinación constante y comienza a apoyarse en activos y reglas compartidas. ### 13.5.5. Valor para la innovación CAPS permite: - Probar nuevas soluciones de forma controlada. - Distinguir experimentos de estándares. - Evaluar innovaciones con evidencia. - Incorporar nuevas tecnologías sin fragmentar el sistema. - Reemplazar implementaciones sin perder los patrones. - Documentar nuevas variaciones. - Retirar soluciones que han perdido valor. - Evitar que la novedad técnica sustituya el análisis del problema. La innovación no se limita a crear más componentes. Consiste en aumentar la capacidad del sistema para responder mejor a nuevas necesidades. ### 13.5.6. Valor para la inteligencia artificial CAPS proporciona el contexto necesario para que las herramientas de IA trabajen de manera institucionalmente útil. Permite: - Vincular prompts con patrones. - Definir entradas y salidas. - Establecer restricciones. - Proporcionar ejemplos validados. - Reducir variabilidad. - Facilitar revisión humana. - Prevenir la creación descontrolada de código. - Automatizar tareas estables. - Mejorar la recuperación del conocimiento. - Mantener responsabilidad profesional sobre las decisiones. La IA deja de operar como una fuente aislada de soluciones y se convierte en una interfaz para aplicar el conocimiento de CAPS. ## 13.6. Estado futuro esperado En su estado futuro, CAPS deberá formar parte natural del proceso de producción. Una solicitud de curso podrá recorrer una secuencia como la siguiente: 1. Se identifica la necesidad. 2. CAPS ayuda a reconocer patrones aplicables. 3. Se seleccionan plantillas y componentes validados. 4. La IA puede apoyar la preparación o adaptación. 5. Los especialistas validan las dimensiones relevantes. 6. El curso se publica. 7. Los aprendizajes regresan al sistema. 8. Los patrones se mejoran con nueva evidencia. La persona encargada del montaje no necesitará memorizar todas las soluciones ni comenzar cada trabajo desde cero. El catálogo podrá orientar: - Qué patrones existen. - Qué información se necesita. - Qué variaciones están permitidas. - Qué riesgos deben considerarse. - Qué implementación es vigente. - Qué revisión es necesaria. - Qué automatización puede utilizarse. Este estado no elimina el trabajo profesional. Reduce el esfuerzo dedicado a reconstruir conocimiento ya disponible. ## 13.7. CAPS como plataforma de capacidades Aunque su nombre incluye la palabra “System”, CAPS no debe limitarse a una herramienta o aplicación. CAPS es una plataforma de capacidades compuesta por: - Un marco estratégico. - Un lenguaje común. - Patrones. - Criterios. - Plantillas. - Componentes. - Implementaciones. - Casos. - Lecciones. - Responsabilidades. - Mecanismos de validación. - Datos de producción. - Automatizaciones. - Herramientas de consulta. La plataforma tecnológica que soporte estos elementos podrá evolucionar. CAPS debe poder comenzar en una herramienta sencilla y posteriormente integrarse con: - Repositorios técnicos. - Sistemas de gestión de proyectos. - Moodle. - Herramientas de inteligencia artificial. - Flujos de automatización. - Tableros de medición. - Sistemas institucionales de conocimiento. La tecnología sirve a la arquitectura. No la define. ## 13.8. CAPS como sistema operativo de producción A largo plazo, CAPS puede convertirse en una especie de sistema operativo para la producción de cursos. Esta expresión no significa que sea un software equivalente a un sistema operativo tecnológico. Significa que CAPS ofrecerá una base compartida sobre la cual las personas podrán: - Interpretar solicitudes. - Seleccionar soluciones. - Coordinar contribuciones. - Ensamblar cursos. - Validar resultados. - Conservar conocimiento. - Automatizar tareas. - Mejorar capacidades. Así como un sistema operativo tecnológico proporciona reglas e interfaces para ejecutar diferentes aplicaciones, CAPS proporcionará patrones e interfaces para que distintas disciplinas puedan trabajar sobre una arquitectura común. Esta visión debe conservarse como una aspiración, no como una justificación para aumentar innecesariamente el alcance inicial. ## 13.9. Integridad conceptual en el futuro El crecimiento de CAPS incorporará: - Más personas. - Más componentes. - Más tipos de cursos. - Más herramientas. - Más automatizaciones. - Más necesidades institucionales. Este crecimiento aumentará el riesgo de fragmentación. Por ello, la integridad conceptual deberá conservarse mediante: - Principios estables. - Vocabulario compartido. - Patrones centrados en problemas. - Límites de responsabilidad. - Decisiones arquitectónicas visibles. - Gobernanza proporcional. - Revisión de duplicaciones. - Retiro de complejidad innecesaria. - Una voz arquitectónica común. La integridad conceptual no deberá convertirse en uniformidad absoluta. CAPS debe permitir diversidad de cursos, públicos y experiencias, siempre que las variaciones: - Respondan a una necesidad. - Conserven criterios fundamentales. - Puedan explicarse. - Sean sostenibles. - No fragmenten innecesariamente el sistema. ## 13.10. Límites que deben conservarse ### CAPS no sustituye el diseño curricular Los expertos académicos y responsables pedagógicos continúan definiendo objetivos, contenidos, actividades y evaluación. ### CAPS no reemplaza el criterio profesional Los patrones orientan decisiones, pero no eliminan el análisis del contexto. ### CAPS no debe estandarizar todo Solo deben estandarizarse necesidades recurrentes cuando la estandarización produzca valor. ### CAPS no debe centralizar todas las decisiones Los cambios locales deben conservar autonomía dentro de límites claros. ### CAPS no debe convertir cada solución en un activo El catálogo debe contener conocimiento útil y reutilizable, no una copia completa de todo el trabajo realizado. ### CAPS no debe depender de una herramienta específica La plataforma puede cambiar sin perder la arquitectura. ### CAPS no debe automatizar la responsabilidad Las decisiones pedagógicas, institucionales, de seguridad y de calidad permanecen bajo control humano. ### CAPS no debe crecer sin retirar La evolución incluye simplificar, consolidar y eliminar activos innecesarios. Estos límites protegen al framework de convertirse en una estructura demasiado amplia o difícil de mantener. ## 13.11. Resultados estratégicos esperados ### Resultado 1: Mayor capacidad de respuesta El área puede atender más solicitudes sin aumentar proporcionalmente el esfuerzo, la coordinación o el retrabajo. ### Resultado 2: Mayor consistencia Los cursos mantienen criterios compartidos de organización, experiencia, funcionamiento y calidad. ### Resultado 3: Mayor autonomía Las personas pueden consultar y aplicar conocimiento sin depender constantemente de expertos específicos. ### Resultado 4: Mayor capacidad de aprendizaje Cada proyecto aporta información que fortalece los activos, decisiones y prácticas futuras. Estos resultados deben mantenerse conectados. Aumentar capacidad sin consistencia, autonomía o aprendizaje no constituye el éxito esperado de CAPS. ## 13.12. Relación con otras áreas ### Para las áreas solicitantes CAPS puede ofrecer: - Mayor claridad sobre la información requerida. - Tiempos más previsibles. - Soluciones consistentes. - Menor cantidad de correcciones evitables. - Mayor transparencia sobre posibilidades y restricciones. - Capacidad de reutilizar soluciones entre proyectos. ### Para los profesores y expertos CAPS puede ofrecer: - Estructuras claras para entregar contenidos. - Plantillas comprensibles. - Mejor organización de recursos. - Menor esfuerzo en decisiones de montaje. - Cursos más fáciles de gestionar y actualizar. ### Para tecnología CAPS puede ofrecer: - Mejor documentación de componentes. - Menor proliferación de scripts. - Dependencias visibles. - Decisiones técnicas trazables. - Criterios para evaluar integraciones. - Mayor control sobre riesgos. ### Para la institución CAPS puede ofrecer: - Conservación del conocimiento. - Mayor capacidad productiva. - Mejor aprovechamiento de inversiones tecnológicas. - Estandarización selectiva. - Evidencia para la planeación. - Base para innovación y automatización. ## 13.13. Sostenibilidad de CAPS CAPS será sostenible cuando su mantenimiento forme parte del trabajo real y no dependa de esfuerzos extraordinarios. La sostenibilidad requiere: - Responsables visibles. - Fichas simples. - Priorización. - Integración con los proyectos. - Revisión proporcional. - Medición limitada y útil. - Distribución de conocimiento. - Retiro de activos obsoletos. - Apoyo estratégico. - Valor observable para sus usuarios. CAPS no será sostenible si: - Depende de una única persona. - Exige documentación extensa. - No se utiliza en proyectos reales. - Acumula componentes sin curaduría. - Cambia constantemente de estructura. - Automatiza sin capacidad de mantenimiento. - No demuestra beneficios. - Se percibe como una obligación adicional sin utilidad. La sostenibilidad debe considerarse un criterio arquitectónico, no solamente una responsabilidad administrativa. ## 13.14. Condiciones para el escalamiento CAPS podrá ampliarse cuando existan evidencias de que: - El catálogo mínimo resulta útil. - Los patrones se reutilizan. - Las personas comprenden el modelo. - Los activos tienen responsables. - La validación funciona. - Los aprendizajes regresan al sistema. - La herramienta soporta el volumen. - Existen resultados medibles. - La complejidad adicional está justificada. - Las nuevas áreas comparten una necesidad compatible. El escalamiento no debe basarse únicamente en el entusiasmo inicial. Cada ampliación debe responder: - Qué capacidad se necesita. - Qué valor producirá. - Qué coordinación adicional exige. - Qué responsabilidad de mantenimiento introduce. - Qué evidencia permitirá evaluarla. ## 13.15. Futuro de la automatización En una etapa madura, CAPS puede permitir que herramientas de IA: - Reconozcan necesidades a partir de una solicitud. - Recomienden patrones. - Soliciten información faltante. - Seleccionen plantillas. - Estructuren contenidos. - Generen implementaciones iniciales. - Comprueben reglas básicas. - Identifiquen inconsistencias. - Sugieran activos relacionados. - Resuman aprendizajes. - Detecten necesidades recurrentes. Sin embargo, la automatización futura deberá conservar tres condiciones: ### Trazabilidad Debe ser posible conocer qué patrón y criterios orientaron el resultado. ### Control humano Una persona competente debe conservar la responsabilidad sobre la validación y publicación. ### Reversibilidad La organización debe poder modificar, desactivar o sustituir la automatización. La visión no es una fábrica autónoma de cursos. Es una producción asistida por conocimiento institucional, en la que la tecnología reduce trabajo repetitivo y las personas concentran su esfuerzo en decisiones de mayor valor. ## 13.16. Futuro del conocimiento A medida que CAPS evolucione, el catálogo podrá pasar de una estructura documental a una base de conocimiento más dinámica. Podrá: - Conectar patrones con datos de uso. - Mostrar los activos más efectivos. - Identificar relaciones entre problemas. - Recomendar alternativas. - Señalar componentes con incidentes. - Detectar patrones sin mantenimiento. - Facilitar búsquedas semánticas. - Apoyar asistentes especializados. - Integrar aprendizajes entre programas. - Conservar decisiones institucionales. La tecnología utilizada para alcanzar este estado deberá seleccionarse cuando la necesidad y el volumen lo justifiquen. La prioridad inicial continúa siendo la calidad del conocimiento, no la sofisticación de la plataforma. ## 13.17. Narrativa institucional de CAPS CAPS puede presentarse institucionalmente mediante la siguiente narrativa: > El área no busca únicamente producir cursos con mayor rapidez. Busca construir una capacidad que permita aprender de cada proyecto, reutilizar soluciones validadas y responder de manera sostenible a una demanda creciente. > CAPS organiza el conocimiento pedagógico, visual, técnico y operativo mediante patrones compartidos. Estos patrones facilitan la colaboración, reducen decisiones repetitivas y proporcionan una base confiable para la automatización y la inteligencia artificial. > Cada curso deja de ser un esfuerzo aislado y se convierte en una oportunidad para fortalecer la capacidad institucional de producción digital. Esta narrativa permite comunicar CAPS sin reducirlo a un repositorio, una biblioteca de código o una herramienta tecnológica. ## 13.18. Compromisos de CAPS ### Con los estudiantes Construir experiencias más claras, coherentes y accesibles. ### Con los profesores Facilitar cursos organizados, mantenibles y comprensibles. ### Con las áreas solicitantes Ofrecer una capacidad de respuesta más predecible y sostenible. ### Con el equipo de producción Reducir trabajo repetitivo y conservar el conocimiento generado. ### Con la institución Convertir experiencia operativa en una capacidad estratégica. ### Con la innovación Incorporar nuevas herramientas mediante criterios, evidencia y responsabilidad. ## 13.19. Declaración de futuro > **CAPS permitirá que el área produzca cursos a partir de una memoria institucional activa, en la que cada patrón representa conocimiento validado, cada componente responde a un propósito y cada proyecto contribuye a mejorar la capacidad del sistema.** > **La eficiencia no dependerá únicamente de trabajar más rápido, sino de reducir la complejidad, reutilizar decisiones y coordinar diferentes especialidades mediante una arquitectura común.** > **La inteligencia artificial ampliará esta capacidad, pero no sustituirá el criterio, la responsabilidad ni la integridad conceptual que sostienen la calidad institucional.** ## 13.20. Cierre del documento fundacional CAPS parte de una realidad concreta: el área ya posee conocimiento, componentes, soluciones y experiencias valiosas, pero una parte importante de ese conocimiento todavía se encuentra distribuida entre personas, proyectos, códigos y herramientas. El framework propone transformar esa experiencia en una capacidad institucional. Para lograrlo, CAPS establece: - Un manifiesto. - Un contexto estratégico. - Una definición común. - Un marco conceptual. - Principios arquitectónicos. - Una arquitectura de capacidades. - Un modelo operativo. - Un modelo organizacional. - Un catálogo de activos. - Una gobernanza ligera. - Un modelo de madurez. - Una hoja de ruta progresiva. Estos elementos no constituyen un sistema terminado. Constituyen la arquitectura necesaria para empezar a construirlo con claridad. CAPS deberá evolucionar mediante proyectos reales, decisiones sencillas, evidencia de uso y aprendizaje continuo. Su principio fundacional permanece: > **Cada curso que construimos mejora el sistema. > Cada mejora del sistema hace que el siguiente curso pueda construirse con mayor claridad, calidad y eficiencia.** La aspiración final no es producir una mayor cantidad de componentes ni acumular documentación. La aspiración es construir una organización capaz de aprender de su producción, conservar su conocimiento y ampliar de manera sostenible su capacidad para responder a las necesidades educativas de la institución. --- # Anexos de validación ## Anexo A. Patrón demostrador ### PAT-001 — Organización de lecturas y recursos académicos #### A. Identificación | Campo | Valor | |---|---| | Tipo de activo | Patrón | | Código | PAT-001 | | Nombre | Organización de lecturas y recursos académicos | | Estado | Candidato | | Versión | 0.1 | | Responsable provisional | Por designar durante el piloto | | Pilar principal | Organización de información | | Pilares relacionados | Pedagogía; experiencia y comunicación visual; técnica y componentes | | Momento del curso | Desarrollo | | Nivel inicial de riesgo | Bajo o medio, según la implementación | | Última revisión | 27 de julio de 2026 | #### B. Problema Los cursos necesitan presentar lecturas, documentos, videos, sitios web y otros recursos académicos. Cuando estos elementos se incorporan sin una estructura compartida pueden mezclarse recursos obligatorios y complementarios, faltar información para reconocerlos, aumentar la extensión visual, utilizarse enlaces ambiguos o seleccionarse componentes que dificultan la consulta. #### C. Propósito Organizar los recursos académicos de una unidad de manera que el estudiante pueda reconocer: - Qué debe consultar obligatoriamente. - Qué recursos son complementarios. - Qué tipo de recurso encontrará. - Qué información necesita para identificarlo. - Cómo acceder a él. - Qué relación tiene con el aprendizaje o la actividad. #### D. Resultado esperado Una presentación comprensible, accesible y mantenible de los recursos académicos, con una jerarquía que refleje su prioridad y permita actualizar enlaces, títulos o referencias sin reconstruir toda la sección. #### E. Contextos de uso El patrón resulta apropiado cuando: - Una unidad contiene dos o más recursos. - Deben distinguirse recursos requeridos y complementarios. - Los materiales incluyen distintos formatos. - Es necesario presentar referencias o información descriptiva. - La cantidad de recursos exige una estructura repetible. - Los mismos criterios se aplicarán en varias unidades. #### F. Situaciones en las que no debe utilizarse No debe utilizarse automáticamente cuando: - Existe un único recurso y una presentación directa resulta más clara. - Moodle ya ofrece una actividad o recurso nativo que comunica suficientemente su propósito. - El elemento forma parte de una secuencia evaluativa que requiere instrucciones específicas. - La solución visual oculta información esencial o dificulta el acceso. - Se propone un carrusel, acordeón u otra interacción únicamente para reducir la extensión, sin comprobar que mejora la consulta. #### G. Información de entrada Para aplicar el patrón se requiere: - Clasificación del recurso como requerido o complementario. - Título. - Autor o entidad, cuando corresponda. - Tipo de recurso. - Enlace o archivo. - Referencia bibliográfica requerida por el contexto académico. - Descripción breve o propósito, cuando sea necesaria. - Condiciones de acceso. - Orden o secuencia prevista. #### H. Criterios obligatorios 1. Diferenciar de forma comprensible los recursos requeridos y complementarios. 2. Utilizar títulos o etiquetas de enlace que comuniquen su destino. 3. Identificar el tipo de recurso cuando no resulte evidente. 4. Comprobar enlaces, archivos y permisos antes de publicar. 5. Conservar una jerarquía de información consistente. 6. No depender exclusivamente del color o de un icono para comunicar prioridad o tipo. 7. Permitir navegación y operación mediante teclado cuando exista interacción. 8. Mantener legibilidad y funcionamiento en pantallas pequeñas. 9. Evitar código o scripts que no sean necesarios para resolver el problema. 10. Permitir que otra persona actualice los recursos sin depender del autor del componente. #### I. Criterios recomendados - Explicar brevemente la relación del recurso con la unidad cuando no sea evidente. - Mantener una cantidad limitada de metadatos visibles. - Aplicar una misma estructura dentro del curso. - Priorizar recursos nativos de Moodle o HTML sencillo cuando resuelvan adecuadamente la necesidad. - Utilizar una variación compacta únicamente cuando la cantidad de recursos lo justifique. - Informar condiciones de acceso externo o autenticación. #### J. Elementos adaptables Pueden adaptarse: - Títulos y descripciones. - Cantidad de recursos. - Orden. - Iconografía autorizada. - Presentación mediante lista, tarjetas o variante compacta. - Información bibliográfica visible. - Agrupaciones adicionales justificadas por el curso. No deben alterarse sin revisar el patrón: - La distinción de prioridad. - La claridad del acceso. - Los criterios de accesibilidad. - La información mínima de identificación. - La capacidad de actualización. #### K. Variaciones candidatas | Variación | Contexto | |---|---| | Lista básica | Pocos recursos y baja densidad de información | | Tarjetas de recursos | Recursos heterogéneos que necesitan descripción o metadatos | | Presentación compacta | Cantidad alta de recursos con información homogénea | | Agrupación por propósito | Recursos organizados por actividad, tema o momento de consulta | Las variaciones deberán comprobar que resuelven una condición recurrente. Un cambio de color, imagen o cantidad no constituye por sí solo una variación. #### L. Componentes e implementaciones relacionadas | Código provisional | Activo | Función | Estado | |---|---|---|---| | CMP-001 | Lista agrupada de recursos | Presentación lineal por prioridad o propósito | Candidato | | CMP-002 | Tarjeta de recurso académico | Presentación con descripción y metadatos | Candidato | | CMP-003 | Indicador de tipo de recurso | Apoyo visual y textual para reconocer el formato | Candidato | | IMP-001 | HTML compatible con Moodle | Implementación de lista o tarjetas sin scripts | Por revisar | | IMP-002 | Recursos nativos de Moodle | Implementación mediante archivos, URL y etiquetas | Por documentar | #### M. Reglas de composición El patrón puede combinarse con: - Orientación inicial de una unidad. - Organización visual de unidades o semanas. - Presentación de actividades. - Comunicación de documentos institucionales. La composición deberá evitar: - Repetir la misma información en varios componentes. - Anidar interacciones que dificulten la navegación. - Separar la orientación pedagógica del acceso al recurso de forma que el estudiante pierda el contexto. - Utilizar simultáneamente variaciones que comuniquen la misma jerarquía de maneras contradictorias. #### N. Pasos generales de aplicación 1. Inventariar los recursos. 2. Confirmar su prioridad y propósito. 3. Completar la información mínima. 4. Seleccionar la variación más simple que responda a la cantidad y diversidad. 5. Preparar los contenidos. 6. Aplicar un componente o implementación compatible. 7. Revisar la estructura en vista de estudiante. 8. Comprobar accesibilidad, enlaces, permisos y comportamiento adaptable. 9. Registrar únicamente las adaptaciones o aprendizajes relevantes. #### O. Criterios de aceptación | Dimensión | Criterio de aceptación | Evidencia | |---|---|---| | Información | Todos los recursos tienen prioridad, identificación y acceso comprensibles | Lista de comprobación | | Pedagogía | La organización permite reconocer qué consultar y con qué propósito | Revisión pedagógica | | Funcionalidad | Enlaces, archivos y permisos funcionan en vista de estudiante | Prueba en Moodle | | Visual | La jerarquía es consistente y no produce sobrecarga evitable | Revisión visual | | Adaptabilidad | La solución se mantiene legible y operable en pantallas pequeñas | Prueba responsiva | | Accesibilidad | La prioridad y el acceso no dependen exclusivamente de recursos visuales | Revisión de accesibilidad | | Mantenimiento | Otra persona puede actualizar los recursos con las instrucciones disponibles | Prueba de uso por un tercero | | Reutilización | La solución puede aplicarse en otra unidad conservando los criterios | Segundo caso o revisión comparativa | #### P. Riesgos y limitaciones - Sobrecargar las tarjetas con información bibliográfica. - Utilizar demasiados iconos o categorías. - Ocultar recursos dentro de interacciones innecesarias. - Duplicar archivos o enlaces ya disponibles mediante recursos nativos. - Aplicar código incompatible con el editor, el tema o la versión de Moodle. - Confundir una variante visual con un patrón pedagógico diferente. #### Q. Evidencia requerida para validación Para pasar de candidato a validado deberá: - Aplicarse, como mínimo, en contextos suficientemente diferentes para comprobar su adaptabilidad. - Ser utilizado o interpretado por una persona distinta de quien lo documentó. - Superar los criterios de aceptación aplicables. - Registrar dificultades, adaptaciones y tiempo de aplicación. - Demostrar que la estructura aporta claridad o reduce una decisión repetitiva. - Contar con una implementación mantenible y un responsable. Los casos concretos y los umbrales de medición se definirán al establecer la línea base del piloto. --- ## Anexo B. Propuesta de piloto fundacional ### B.1. Objetivo Comprobar que CAPS permite encontrar, comprender, aplicar, validar y mejorar patrones de montaje dentro de proyectos reales, sin introducir una carga de coordinación mayor que el beneficio obtenido. ### B.2. Alcance El piloto comprenderá: - Entre cinco y diez patrones candidatos. - Uno o dos cursos o proyectos reales. - Un catálogo mínimo. - Un conjunto reducido de componentes e implementaciones. - Una ficha canónica. - Validación proporcional al riesgo. - Registro básico de uso, tiempo, correcciones y aprendizajes. No comprenderá: - Migración completa del repositorio. - Automatización de publicación. - Integración automática con Moodle. - Extensión institucional. - Aprobación definitiva de todas las tipologías. ### B.3. Patrones iniciales propuestos | Prioridad | Patrón candidato | Razón inicial | |---|---|---| | 1 | Organización de lecturas y recursos académicos | Alta recurrencia y diversidad de implementaciones | | 2 | Presentación del profesor o equipo docente | Estructura repetible con información reconocible | | 3 | Comunicación de cronogramas y fechas | Impacto en orientación y actualización | | 4 | Orientación y bienvenida de una unidad | Presencia frecuente y relación pedagógica directa | | 5 | Navegación de retorno | Problema concreto de navegación en contenidos | La selección definitiva dependerá del inventario y de los cursos disponibles. ### B.4. Selección de cursos Se recomienda seleccionar: - Un curso que represente una estructura recurrente y estable. - Un curso con suficiente variación para probar adaptabilidad. Los cursos deberán: - Encontrarse dentro de un ciclo real de montaje o actualización. - Permitir participación de los perfiles responsables. - Contar con contenidos y condiciones suficientemente definidos. - No depender de una ventana de entrega que impida registrar aprendizajes. - Evitar, en la primera prueba, riesgos técnicos o de publicación excesivos. ### B.5. Responsabilidades provisionales | Función | Responsabilidad durante el piloto | |---|---| | Patrocinio u orientación estratégica | Autorizar alcance, participantes y tiempo | | Arquitectura CAPS | Proteger conceptos, resolver duplicaciones y consolidar decisiones | | Curaduría | Organizar fichas, estados, relaciones y observaciones | | Montaje | Aplicar patrones y registrar dificultades | | Revisión pedagógica | Verificar intención, claridad y orientación | | Revisión visual y de accesibilidad | Verificar jerarquía, adaptabilidad y accesibilidad | | Revisión técnica | Comprobar funcionamiento, compatibilidad y mantenimiento | Una persona puede asumir más de una función durante esta etapa, siempre que los derechos de decisión permanezcan explícitos. ### B.6. Secuencia 1. Confirmar participantes, cursos y patrones. 2. Registrar una línea base ligera. 3. Configurar el catálogo mínimo. 4. Documentar los patrones candidatos. 5. Revisar y clasificar los componentes necesarios. 6. Aplicar los patrones en los cursos. 7. Validar los resultados. 8. Registrar casos y aprendizajes. 9. Decidir el estado de cada activo. 10. Consolidar recomendaciones para la siguiente versión. ### B.7. Información mínima de línea base - Tiempo aproximado para localizar o construir una solución. - Número de consultas necesarias para comprenderla. - Correcciones asociadas con inconsistencias, enlaces o funcionamiento. - Soluciones creadas desde cero. - Componentes reutilizados. - Dependencia respecto del autor del recurso. - Percepción de claridad y autonomía de los participantes. ### B.8. Condiciones de éxito El piloto se considerará suficientemente exitoso cuando exista evidencia de que: - Una persona distinta del autor puede localizar y aplicar al menos un patrón. - Los activos utilizados cumplen los criterios definidos. - La consulta de CAPS reduce alguna decisión o búsqueda repetitiva. - Las adaptaciones necesarias pueden distinguirse de cambios al patrón. - Los problemas encontrados producen modificaciones trazables. - La revisión se concentra en riesgos relevantes. - El equipo puede identificar qué debe conservarse, corregirse o retirarse. - El costo de documentar y coordinar resulta razonable frente al valor obtenido. Los objetivos cuantitativos se fijarán después de establecer la línea base; no deberán inventarse umbrales sin evidencia previa. ### B.9. Resultados esperados - Catálogo mínimo utilizable. - Patrones candidatos aplicados. - Componentes clasificados. - Casos de aplicación. - Lecciones aprendidas. - Registro de tiempos y correcciones. - Decisiones sobre validación, continuidad o retiro. - Recomendaciones para la siguiente versión operativa después del piloto. --- ## Anexo C. Instrumento de observaciones ### C.1. Matriz | ID | Revisor y función | Sección o activo | Tipo | Observación y evidencia | Impacto | Acción propuesta | Decisión | Responsable | Estado | |---|---|---|---|---|---|---|---|---|---| | OBS-001 | Por diligenciar | Por diligenciar | Por diligenciar | Por diligenciar | Por diligenciar | Por diligenciar | Pendiente | Por asignar | Abierta | ### C.2. Tipos de observación - Conceptual. - Estratégica. - Pedagógica. - Organización de información. - Visual o de experiencia. - Accesibilidad. - Técnica. - Operativa. - Organizacional. - Medición. - Editorial. - Recomendación futura. ### C.3. Niveles de impacto **Crítico:** impide aprobar el fundamento o iniciar el piloto por contradicción, riesgo o inviabilidad. **Alto:** afecta el alcance, una responsabilidad, un principio o una capacidad esencial. **Medio:** requiere aclaración o ajuste, pero no impide continuar la validación. **Bajo:** corresponde a redacción, ejemplo, precisión o mejora editorial. ### C.4. Decisiones posibles - Aceptada. - Aceptada parcialmente. - Requiere análisis adicional. - Se incorpora al piloto. - Se aplaza para una versión posterior. - No aceptada, con justificación. - Cerrada por aclaración. Toda observación crítica o alta deberá contar con una decisión explícita antes de aprobar la versión 1.0. Las observaciones medias o bajas podrán agruparse editorialmente cuando no alteren el sentido. --- ## Anexo D. Proceso de socialización y validación | Etapa | Participantes | Propósito | Resultado | |---|---|---|---| | 1. Prevalidación estratégica | Jefatura, coordinación y promotor de CAPS | Confirmar problema, alcance, respaldo y responsables provisionales | Autorización para socializar | | 2. Revisión especializada | Diseño instruccional, producción Moodle, diseño visual, accesibilidad y perfil técnico | Revisar conceptos, viabilidad, riesgos y responsabilidades | Observaciones clasificadas | | 3. Socialización con el equipo | Personas que montan, revisan y coordinan cursos | Contrastar CAPS con la experiencia y priorizar necesidades | Patrones y cursos candidatos | | 4. Consolidación | Arquitectura y curaduría provisionales | Resolver observaciones y preparar la decisión | Versión candidata a aprobación | | 5. Decisión fundacional | Instancia responsable | Aprobar, ajustar o aplazar el paso a pilotaje | Versión 1.0 aprobada para piloto o plan de ajustes | | 6. Pilotaje | Equipo y cursos seleccionados | Probar el modelo en producción real | Evidencia, casos y lecciones | | 7. Revisión posterior | Coordinación, arquitectura y equipo piloto | Evaluar continuidad, ampliación o simplificación | Siguiente versión operativa | ### D.1. Sesión principal sugerida La socialización principal puede desarrollarse en una sesión de 60 a 90 minutos: 1. Contexto y problema: 10 minutos. 2. Propuesta de CAPS: 15 minutos. 3. Ejemplo PAT-001: 15 minutos. 4. Modelo operativo y responsabilidades: 10 minutos. 5. Propuesta de piloto: 10 minutos. 6. Validación y conversación: 20 a 30 minutos. La sesión no deberá recorrer todos los capítulos. El documento completo funciona como referencia; la presentación deberá concentrarse en el problema, la arquitectura propuesta, el ejemplo, las decisiones abiertas y el piloto. ### D.2. Regla de consolidación La socialización no equivale a aprobación. Toda observación deberá registrarse, clasificarse y recibir una decisión. La versión 1.0 se publicará únicamente cuando el órgano responsable confirme el fundamento y autorice el alcance del piloto. --- ## Control del documento | Campo | Valor | |---|---| | Documento | Course Assembly Pattern System — CAPS | | Tipo | Documento fundacional | | Versión | 0.9 | | Estado | Propuesta fundacional consolidada para validación | | Fecha de corte | 27 de julio de 2026 | | Responsable de consolidación | Por registrar | | Instancia de validación | Por definir durante la alineación institucional | | Próxima revisión | Después de la revisión especializada y la socialización con el equipo | ### Historial de cambios | Versión | Fecha | Descripción | Estado | |---|---|---|---| | 0.9 | 27 de julio de 2026 | Preparación de la propuesta para validación: resumen ejecutivo, alcance, decisiones abiertas, fundamento teórico, patrón demostrador, piloto e instrumentos de observación y socialización | En validación | | 1.0 | Por definir | Incorporación de observaciones y decisión fundacional para el pilotaje | Pendiente |