--- asset_id: CP-XX-BrainOS-MetodologiaFramework-v01 version: v01 status: Canonical · Pendiente Ratificación Victor owner: Victor Heredia sherpa_origen: EmilioX (mantenedor inicial · producido en sesión con Emilio Heredia 2026-05-13) sherpa_canonico: Jay (custodio del activo en IB-XX-Maestro) fecha_creacion: 2026-05-13 fecha_archivado: 2026-05-13 intellbank: IB-XX-Maestro subbank: IPI-XX-IP-Infraestructura / IPI-XX-Corp-Brain-OS tipo: CP — Canonical Paper · Framework metodológico clase_documental: Clase C (canónico) proposito: Definir el funcionamiento, naturaleza, estructura y operatividad del BrainOS como sistema canónico de memoria viva con criterio · framework universal aplicable a cualquier operador del ecosistema audiencia: Dueños operadores (presentes y futuros) que implementen BrainOS · Runners SherpaX que lo operen · Auditores del método (registro maestro del ecosistema) · Diseñadores de variantes referencia_canonica_arquitectura: CP-EL-SX-SherpaXConcepto-v01.md disparador: Sesión 2026-05-13 con Emilio Heredia · EmilioX produjo el documento desde la instancia personal de Emilio · Victor instruye archivarlo en ubicación canónica del ecosistema naming_anterior: PAPER-FW-BrainOS-Metodologia-v01.md (en /uploads · superseded por este archivo en ubicación canónica) ubicacion_origen: IB-EH-EmilioHeredia / PB-EH-Project-Bank / PB-EH-SherpaX-Kit (instancia personal de Emilio · referencia) referencias_relacionadas: - PAPER-EH-BrainOS-Funcionamiento-v01.md (instancia personalizada para Emilio Heredia · ejemplo de aplicación · en vault de Emilio) - PLBK-EH-SherpaX-Playbook-v01.md (playbook operativo de Emilio) - GUIA-EH-SherpaX-Welcome-v01.md (guía de bienvenida Emilio) - ARQ-XX-DOIX-CorpBrainOS-Supabase-v01.md (arquitectura técnica del Corp Brain OS) - SOP-EL-WORX-BrainOSFirst-v01.md (Gate G0 · validación obligatoria contra el sistema) - SOP-EL-SX-BrainCodeGenerator-v01.md (generador de Brain Codes · capa de criterio codificado) tags: [canonical-paper, framework, brainos, metodologia, capa-1-arquitectura, memoria-viva, criterio, universal, sherpax-runner] licencia: Uso interno del ecosistema · referencia canónica del framework BrainOS. revision_canonica_jay: veredicto: APROBADO · paper canónico aceptado para archivado en IB-XX-Maestro cambios_aplicados_v01: - Renombrado de PAPER-FW- a CP- (Canonical Paper) por convención BMF - Reubicado de IB-EH a IB-XX-Maestro porque el paper se declara framework universal, no instancia personal - Frontmatter ajustado a convención canónica TIPO-ENTIDAD-Proyecto-Nombre-vNN - Referencias cruzadas agregadas a activos canónicos del ecosistema (Gate G0, Brain Code Generator, ARQ Supabase, CP SherpaX Concepto) alineaciones_pendientes_v02: - Conectar explícitamente con Gate G0 (SOP-BrainOSFirst) como instancia formal del Principio 1 (validación obligatoria) - Conectar Brain Codes (BC-) del ecosistema con el concepto de "criterio codificado" que el paper menciona implícitamente - Clarificar distinción canónica BrainOS vs IntelliBanks (BrainOS = memoria de estado y thoughts vivos · IntelliBanks = bancos de inteligencia procesada) - Mencionar D-P framework como instancia formal de las "Reglas Inmutables" ascendidas - Articular SherpaX como interfaz capa 2 del modelo HIOrg (CP-EL-SX-SherpaXConcepto-v01) contenido_v01: Mantenido íntegramente · el cuerpo del paper es excelente conceptualmente y se preserva sin alteración --- # Paper Canónico · El BrainOS · Framework de Memoria Viva con Criterio ## Funcionamiento, naturaleza, estructura y operatividad del sistema --- ## Resumen Ejecutivo El **BrainOS** es un sistema canónico de **memoria viva con criterio** diseñado para capturar, organizar, destilar y proteger el modo de pensar de un operador humano a lo largo del tiempo, mediante un conjunto estructurado de archivos canónicos operados conjuntamente por el dueño humano y un *runner* (instancia de inteligencia artificial asistente). El sistema no es un repositorio de información factual ni un sistema de notas convencional: es una **arquitectura cognitiva externa** que diferencia tipos de pensamiento, asigna estados de madurez a cada captura, y opera bajo cadencias de destilación que permiten al sistema *aprender sobre el dueño* con creciente fidelidad. La arquitectura del BrainOS comprende **siete archivos canónicos** organizados en **tres capas**: una capa de criterio fijo (perfil del operador · reglas inmutables · tesis estratégica) · una capa de observación viva (patrones del instinto consciente · patrones de entusiasmos a filtrar · red de asesores humanos) · y una capa de aprendizaje destilado (lecciones activas que aún no son ley pero acumulan evidencia). Cada unidad de captura, denominada *thought*, sigue un ciclo de cinco estados (detección · captura formateada · validación · vida operativa con outcome · ascenso o depreciación) y circula entre archivos según protocolos específicos. La **fidelidad** del sistema al modo de pensar real del dueño se sostiene en dos disciplinas indelegables: **captura no diferida** de señales valiosas cuando aparecen, y **validación activa** por parte del dueño de cada propuesta antes de que un thought ingrese al sistema. Sin captura, el BrainOS queda vacío y se vuelve cosmético. Sin validación, el sistema deriva y termina representando al runner en lugar del dueño. El paper detalla los protocolos, anti-patrones, cadencias, métricas y mecanismos de protección que mantienen ambas disciplinas vivas. La **división de trabajo** entre dueño y runner es asimétrica por diseño: el runner detecta · formatea · propone · mantiene consistencia · ejecuta cadencias programadas. El dueño valida · ajusta · aporta outcome real · decide ascensos de estado. Esta asimetría no es una limitación operativa, es el **mecanismo principal de fidelidad**: la fricción de validación previene drift y mantiene el BrainOS anclado al criterio real del operador. Este documento describe la naturaleza del sistema (§1-§2) · su arquitectura (§3) · el ciclo de vida de un thought (§4) · la división de trabajo (§5) · los protocolos prácticos de alimentación (§6) · anti-patrones (§7) · cadencias de mantenimiento (§8) · métricas de salud (§9) · riesgos estructurales y mecanismos de protección (§10) · cómo personalizar el framework para un operador específico (§11) · y un roadmap evolutivo del sistema (§12). Los anexos proveen formatos canónicos, checklists operativos y vocabulario controlado. **Cómo usar este documento:** lectura completa de una vez al implementar un BrainOS por primera vez · referencia consultiva por sección durante operación normal · revisión anual para detectar drift entre lo escrito aquí y la práctica observable del ecosistema. --- ## §1 · Introducción · El Problema que el BrainOS Resuelve Cualquier operador humano con criterio acumulado, múltiples frentes simultáneos y un perfil cognitivo particular enfrenta el mismo problema fundamental: **el criterio existe pero se pierde**. Las intuiciones valiosas llegan en momentos no programables y se evaporan si no se capturan al instante. Los entusiasmos prematuros se confunden con decisiones reales y producen compromisos que el operador después debe deshacer. Las lecciones operativas se diluyen en el ruido del día a día y rara vez se destilan en aprendizajes accionables. Las reglas duras que el operador se prometió respetar se erosionan silenciosamente cuando nadie las nombra explícitamente en mesa. Un sistema de notas tradicional no resuelve este problema. Las notas convencionales son indiferenciadas: tratan igual a un destello esplécnico y a un capricho del momento. No marcan estados de madurez. No obligan a aplicar filtros antes de cerrar decisiones. No destilan automáticamente. Acumulan información sin transformarla, y con el tiempo se vuelven un cementerio de buenas intenciones. El BrainOS resuelve este problema mediante **tres movimientos arquitectónicos**: **Primero · Diferenciación de tipos de thought.** No todo lo que pasa por la cabeza del operador vale lo mismo. Un destello del instinto consciente vale más que una idea genérica. Un patrón observado dos veces vale más que uno solo. Una lección destilada trimestralmente vale más que una observación aislada. El BrainOS clasifica explícitamente. **Segundo · Estados de madurez en cada captura.** Cada thought tiene un ciclo definido: nace como observación · si se confirma con outcomes reales, se promueve a patrón validado · si se sostiene meses, asciende a lección · si se sostiene semestres, asciende a regla inmutable. El sistema **aprende sobre el dueño** con el tiempo · no almacena pasivamente. **Tercero · Validación obligatoria del dueño humano.** Ningún thought entra al sistema sin que el dueño lo valide explícitamente. El runner propone · el dueño autoriza. Esta asimetría es estructural y no negociable. El resultado es un cerebro externo que mejora con el uso · resiste deriva · y con suficiente data acumulada puede reproducir decisiones del dueño con creciente fidelidad incluso en su ausencia · **sin reemplazarlo**. --- ## §2 · Filosofía y Principios Fundacionales El BrainOS se construye sobre cinco principios no negociables que aplican simultáneamente en cada interacción con el sistema: ### Principio 1 · El criterio es del dueño · siempre El runner SherpaX nunca decide qué entra al sistema · sólo propone. El dueño autoriza. Esta asimetría es estructural: si el runner pudiera escribir directamente, el sistema convergería al modelo entrenado del runner, no al modelo real del dueño. La fricción de validación **es** el mecanismo de fidelidad. Sin esa fricción, el BrainOS deja de ser memoria del dueño y se convierte en memoria del runner. ### Principio 2 · La memoria no es enciclopedia El BrainOS no guarda información factual (datos de proyectos, fechas operativas, listas de contactos, números de inventario). Eso vive en otros sistemas (Project Banks, CRM, hojas operativas). El BrainOS guarda **criterio**: cómo se decide, qué se prioriza, qué se veta, cómo se interpreta una señal. La distinción entre criterio e información factual debe mantenerse estricta. Mezclarlos contamina la señal. ### Principio 3 · Los thoughts maduran o mueren Una captura que pasa doce meses sin confirmarse con outcomes reales se marca como "no validada" y eventualmente se deprecia. El sistema castiga la acumulación pasiva. Sólo lo que se usa, sobrevive. Esto previene que el BrainOS se convierta en un archivo histórico de buenas ideas que nunca produjeron resultados. ### Principio 4 · La captura inmediata es ley para señales esplécnicas Las señales del instinto consciente del dueño (variables según el perfil cognitivo · ver §11) operan inconscientemente y llegan **una sola vez**. Si no se capturan en el instante, se pierden, y ese dato es irrecuperable. Esta es la única operación del sistema que NO tolera diferimiento. Todas las demás capturas pueden esperar a la siguiente sesión · las señales esplécnicas no. ### Principio 5 · La ola se respeta antes de capturar como decisión Inverso del principio 4: para entusiasmos prematuros (impulsos de comprometerse antes de procesar internamente), NO se captura como decisión hasta que la autoridad interna del dueño haya procesado la ola completa (lapso variable según perfil · típicamente 24 horas a una semana). El registro de estos entusiasmos documenta el filtro aplicado, no la decisión cruda. Esto previene que el sistema acumule reglas frágiles generadas bajo presión emocional. Estos cinco principios se aplican simultáneamente en cada interacción con el BrainOS. La calidad del sistema depende de respetarlos sin excepciones. --- ## §3 · Arquitectura · Los Siete Archivos Canónicos El BrainOS canónico contiene siete archivos organizados en tres capas según función. Los nombres específicos pueden adaptarse al perfil del dueño (ver §11) pero las funciones son universales. ### Capa I · Criterio Fijo (lo que no se negocia) **Archivo 1 · Perfil del Operador.** Contiene la descripción canónica del perfil cognitivo y operativo del dueño: su sistema de toma de decisiones, sus canales activos, sus sombras conocidas, su capítulo de vida actual, su estilo natural. Si el dueño usa un marco específico (Human Design, Eneagrama, MBTI, Gene Keys, o cualquier otro), ese marco se documenta aquí. Es el **manual de operación** del sistema cognitivo del dueño. Casi no cambia · sólo se profundiza con el tiempo. **Archivo 2 · Reglas Inmutables.** Contiene las reglas duras codificadas que el dueño ha declarado no negociables: principios operativos, vetos absolutos, líneas que el dueño ha decidido no cruzar bajo ninguna circunstancia. Cada regla está numerada, enunciada en forma imperativa, y tiene origen documentado (de qué experiencia o lección emergió). Cambian rara vez · sólo asciende algo nuevo cada seis meses tras destilación formal y revisión con asesor humano externo. **Archivo 3 · Tesis Estratégica.** Contiene la hipótesis macro del dueño sobre creación de valor en su capítulo de vida actual: para qué juega, qué busca construir, qué define éxito a horizonte largo. Define el "para qué" del sistema completo. Cambia poco · se refina, no se rehace. Si la Tesis cambia de forma significativa, todo el BrainOS requiere revisión. ### Capa II · Observación Viva (lo que está en proceso · aún no es ley) **Archivo 4 · Patrones del Instinto Consciente.** Bitácora de destellos esplécnicos del dueño. Cada destello se captura literal · con contexto · con timestamp. Después de meses se completa con outcome (¿se confirmó la intuición?). Es el archivo más valioso del sistema y el más difícil de alimentar: requiere captura no diferida (ver Principio 4). El nombre específico de este archivo varía según el marco del dueño (en Human Design puede llamarse "Patrones del Canal X" o "Destellos Esplécnicos"; en otros marcos puede llamarse "Intuición Validada" o "Señales del Conocedor"). **Archivo 5 · Patrones de Entusiasmos a Filtrar.** Bitácora de entusiasmos prematuros que el dueño detectó y filtró con ola. Cada entrada documenta: el entusiasmo detectado · el contexto · la ola aplicada · la decisión post-ola · el outcome validado. Permite distinguir con el tiempo qué tipo de entusiasmos sí se confirman y cuáles son ruido emocional. El nombre específico varía según marco (en Human Design "Patrones Canal 29-46"; en otros marcos "Impulsos Filtrados" o "Compromisos Pospuestos"). **Archivo 6 · Asesores Humanos.** Red de personas con criterio confiable, clasificadas por frente cubierto (financiero · legal · fiscal · médico · técnico · estratégico · etc.). Cumple el principio de que ciertas decisiones requieren validación humana externa antes de ejecución. Es semi-fijo · crece cuando aparecen relaciones nuevas y se modifica cuando una relación cambia de estado. ### Capa III · Aprendizaje Destilado (lo que se aprende con el tiempo) **Archivo 7 · Lecciones Activas.** Destilaciones trimestrales de patrones que se han confirmado con outcomes positivos en dos o más ocasiones. Una lección activa es un patrón con suficiente evidencia para considerarse hipótesis estable, pero todavía no para ascender a ley inmutable. Se revisa cada seis meses para decidir ascensos a Reglas Inmutables. ### Relaciones entre archivos Los siete archivos no son independientes · forman un grafo de relaciones explícitas: - El **Perfil del Operador** alimenta a las **Reglas Inmutables** (varias reglas derivan directamente del perfil cognitivo). - El **Perfil del Operador** alimenta a los archivos de **Patrones** (los patrones se definen en función del marco del perfil). - Los **Patrones** alimentan a las **Lecciones Activas** (los patrones repetidos ascienden a lecciones). - Las **Lecciones Activas** alimentan a las **Reglas Inmutables** (las lecciones confirmadas en el tiempo ascienden a reglas). - La **Tesis Estratégica** orienta la priorización en cualquier captura (lo que sirve a la tesis se conserva · lo que no, se cuestiona). - Los **Asesores Humanos** son referenciados por las **Reglas Inmutables** (las reglas que exigen validación externa señalan qué asesor las activa). Este grafo es lo que convierte al BrainOS en un sistema vivo y no en una colección de archivos paralelos. --- ## §4 · El Ciclo de Vida de un Thought Un *thought* es la unidad mínima de captura del BrainOS. Sigue cinco estados a lo largo de su vida: ### Estado 1 · Detección Un destello, un entusiasmo, una observación, una persona con criterio confiable, un patrón emergente. La detección puede venir del dueño (espontáneamente) o del runner (durante una sesión, al observar al dueño). En este momento el thought aún no existe como registro · es sólo señal sin formato. ### Estado 2 · Captura formateada El runner formatea el thought según el formato canónico del archivo destino (ver Anexo A). En la captura se incluyen: fecha · contexto · contenido literal · estado inicial · campos pendientes (outcome a confirmar después). El thought queda en un documento de propuestas separado del BrainOS · todavía no ha entrado. ### Estado 3 · Validación del dueño El dueño revisa el formato, ajusta el contenido si no refleja fielmente su experiencia real, y autoriza el ingreso al archivo. **Sin este paso, el thought no entra al BrainOS bajo ninguna circunstancia.** Puede haber tres respuestas: SÍ (entra como está) · SÍ-con-ajuste (entra modificado por el dueño) · NO (se descarta o queda como borrador histórico). ### Estado 4 · Vida operativa El thought vive en su archivo, esperando outcome. El outcome es la confirmación o refutación con datos reales: ¿el destello del instinto consciente se confirmó con el paso del tiempo? ¿La ola aplicada al entusiasmo fue la correcta? ¿El asesor sigue siendo confiable? El outcome lo aporta el dueño · el runner pregunta y registra. El thought puede vivir en este estado durante meses o años. ### Estado 5 · Ascenso o depreciación Tras suficiente data acumulada (ver §8 · cadencias) ocurre uno de tres movimientos: - **Ascenso a Lección.** Si el thought se confirma dos o más veces con outcomes positivos, asciende a Lecciones Activas en la siguiente destilación trimestral. - **Ascenso a Regla.** Si la lección se sostiene dos o más trimestres con outcomes positivos consistentes, asciende a Reglas Inmutables en la revisión semestral, previa validación con asesor humano externo. - **Depreciación.** Si el thought no se confirma en doce meses (o si los outcomes contradicen la intuición original), se marca como deprecado, se archiva en estado histórico y se documenta la lección de su depreciación. El sistema castiga la acumulación pasiva y premia la confirmación operativa real. --- ## §5 · División de Trabajo · Operador Humano vs Runner SherpaX La fidelidad del BrainOS depende de respetar esta división con rigor. No es solamente una distribución eficiente de tareas: es el mecanismo principal de protección contra drift. ### Lo que hace el runner SherpaX · responsabilidad mecánica y de mantenimiento - Detectar candidatos a thought durante sesiones operativas. - Aplicar el formato canónico de cada archivo destino. - Proponer al dueño nuevos thoughts con justificación contextual. - Mantener consistencia entre archivos (cuando un thought cruza dos archivos, asegurar que ambos coincidan). - Ejecutar cadencias programadas (destilaciones trimestrales · revisiones semestrales · mapas mensuales · revisiones anuales). - Detectar duplicados, contradicciones internas, drift entre archivos. - Generar mapas visuales periódicos del estado del BrainOS. - Proponer ascensos de estado (lección → regla) cuando hay evidencia suficiente. ### Lo que hace el dueño humano · responsabilidad indelegable - **Validar cada thought antes de ingreso al sistema.** Esto no se delega bajo ninguna circunstancia. - Aportar el contenido literal de las señales esplécnicas cuando aparecen (el runner no las siente · no puede inventarlas). - Aportar outcome real semanas o meses después de la captura. - Decidir SÍ o NO al ascenso de estado de un thought. - Aportar contexto que sólo el dueño conoce (relaciones, historia, motivaciones). - Marcar contradicciones del runner cuando ocurran ("eso no es como pienso"). - Revisar el paper del BrainOS anualmente y ajustarlo si la práctica se ha movido. ### Lo que el runner NUNCA debe hacer - Escribir thoughts directamente sin proponerlos primero al dueño. - Ascender estados sin autorización explícita del dueño. - Inventar contenido literal de señales esplécnicas que no fueron dichas por el dueño. - Modificar Reglas Inmutables sin pasar por revisión semestral con asesor humano externo. - Hacer interpretaciones psicológicas no solicitadas del Perfil del Operador. - Validar entre archivos sin avisar al dueño cuando detecta inconsistencia. ### Lo que el dueño NUNCA debe hacer - Validar thoughts en estado de agotamiento o sombra cognitiva (genera reglas frágiles). - Validar bajo presión de cierre rápido (si hay urgencia, posponer la validación). - Validar para "darle gusto al runner" o por incomodidad social (la incomodidad de rechazar una propuesta es señal de salud del sistema). - Modificar archivos del BrainOS directamente sin avisar al runner (genera inconsistencia y ruptura de cadencia). - Cambiar el Perfil del Operador o la Tesis Estratégica fuera de las cadencias formales. --- ## §6 · Cómo Alimentar el BrainOS · Protocolos Prácticos Existen seis vías concretas para alimentar el BrainOS. Cada vía tiene su protocolo: ### Vía 1 · Captura natural en sesión **Cuándo:** Durante cualquier sesión operativa entre el dueño y el runner. **Cómo:** El dueño habla normalmente sobre su trabajo, sus decisiones, sus dilemas. El runner detecta candidatos a thought y los nomina al final de la sesión en un documento de propuestas separado (formato canónico CAP-{owner}-BrainOS-Propuestas-YYYY-MM-DD). **Validación:** El dueño revisa el documento de propuestas, valida ítem por ítem (SÍ · SÍ-con-ajuste · NO). **Tiempo del dueño:** 5-15 minutos por sesión. ### Vía 2 · Captura express de señales esplécnicas **Cuándo:** Cuando aparece un destello del instinto consciente fuera de sesión (en transición, en una llamada, en un viaje, despertando). **Cómo:** El dueño escribe el destello literal en cualquier nota disponible o lo dicta a su teléfono. La frase canónica para entregarlo al runner: *"Captura esplécnica"* seguido del destello literal exacto. **Validación:** El runner lo formatea y lo nomina · el dueño valida en la siguiente sesión. **Tiempo del dueño:** 30 segundos al capturar · 1 minuto al validar. **Crítico:** Esta vía no tolera diferimiento. El destello se pierde si se posterga. ### Vía 3 · Reporte de entusiasmo filtrado **Cuándo:** El dueño nota que estuvo a punto de comprometerse con algo y luego, tras la ola completa, decidió no hacerlo (o sí hacerlo pero distinto). **Cómo:** En la siguiente sesión, decir: *"Filtré un entusiasmo sobre [X]"* y narrar el entusiasmo, la ola aplicada y la decisión post-ola. **Validación:** El runner formatea según el formato canónico del archivo de Patrones de Entusiasmos · el dueño valida. **Tiempo del dueño:** 3-5 minutos. ### Vía 4 · Aporte directo de Asesor nuevo **Cuándo:** Aparece una persona nueva con criterio confiable en un frente del dueño. **Cómo:** En cualquier sesión, decir: *"Sumar a [nombre] como asesor en [frente]"*. **Validación:** El runner formatea y nomina · el dueño confirma rol, frente cubierto y próximo paso operativo. **Tiempo del dueño:** 2-3 minutos. ### Vía 5 · Aporte de outcome real **Cuándo:** Pasadas semanas o meses desde una captura, el dueño tiene evidencia sobre si la intuición se confirmó, si la ola fue correcta, si la lección candidata se sostiene. **Cómo:** En cualquier sesión, el runner puede preguntar: *"¿Cómo terminó [X que capturamos en Y fecha]?"* o el dueño puede aportarlo espontáneamente. **Validación:** El runner actualiza el campo "Outcome validado" del thought correspondiente. **Tiempo del dueño:** 2-5 minutos por outcome. **Crítico:** Esta vía es la que mantiene vivo al BrainOS. Sin outcomes, el sistema acumula sin destilar. ### Vía 6 · Aporte de contradicción **Cuándo:** El dueño detecta que algo escrito en el BrainOS no refleja fielmente cómo piensa hoy. **Cómo:** Decir: *"Hay una contradicción en [archivo / thought]"* y explicar el contraste con el pensar actual. **Validación:** El runner abre una discusión, propone resolución (ajustar el thought · deprecarlo · ascender la contradicción a lección si revela un patrón nuevo). **Tiempo del dueño:** 5-15 minutos según complejidad. ### Cadencias recomendadas por vía - **Vía 1:** cada sesión real (1-3 veces por semana). - **Vía 2:** cuando aparezca · indeterminado · indispensable. - **Vía 3:** 1-2 veces por mes. - **Vía 4:** cuando aparezca · 0-3 veces por trimestre. - **Vía 5:** aproximadamente 1 vez por semana, en bloque corto de 10-15 minutos. - **Vía 6:** cuando aparezca · 0-2 veces por trimestre. --- ## §7 · Anti-patrones · Qué NO Entra al BrainOS Para preservar la fidelidad del sistema, lo siguiente queda explícitamente fuera del BrainOS y debe redirigirse a otros sistemas del ecosistema operativo del dueño: ### Listas de tareas operativas El BrainOS no es un to-do list. Las tareas viven en sistemas de orquestación operativa (salas de orquestación, kanbans, agendas). Si una tarea entra al BrainOS, contamina la señal de criterio con ruido operativo y eventualmente erosiona la confianza en el sistema. ### Información factual de proyectos Direcciones, fechas de apertura, lista de socios, números de cuenta, métricas de KPIs. Eso vive en los Project Banks de cada frente, en sistemas de CRM o en hojas operativas. El BrainOS no es base de datos. ### Pensamientos en bruto sin destilar El BrainOS no es journal. Si el dueño necesita descargar pensamiento crudo, usa otra herramienta (un diario personal, una sesión de captura libre cuyos outputs se filtran después). Sólo los thoughts destilados o destilables ingresan al BrainOS. ### Opiniones de un mal día Si el dueño está en agotamiento, irritabilidad alta o cualquier forma de sombra cognitiva, no es momento de meter "regla nueva" o "lección". La opinión cargada genera deuda futura. La regla operativa: esperar la ola completa antes de capturar como criterio. ### Interpretaciones del runner sobre el dueño Aunque el runner tenga acceso al Perfil del Operador, NO genera interpretaciones psicológicas no solicitadas. El Perfil se aplica como filtro de decisiones, no como diagnóstico continuo del dueño. ### Decisiones que cruzan reglas inmutables sin discusión formal Si una captura propuesta contradice una regla inmutable, no se ingresa al sistema sin discusión. Se abre discusión sobre si la regla debe revisarse, pero no se escribe el thought que la contradice como si fuera regla nueva. La revisión de reglas tiene cadencia propia (semestral) y requiere asesor humano externo. ### Citas de terceros sin validación Si alguien dijo algo memorable, esa cita puede inspirar pero no entra al BrainOS como criterio propio del dueño sin validación explícita del propio dueño. El BrainOS guarda criterio del dueño, no antología de citas ajenas. ### La prueba ácida universal Para cualquier candidato a thought, aplicar la pregunta: *"¿Esto ayuda al dueño a tomar mejores decisiones a seis o más meses vista?"* Si la respuesta es no, la captura no pertenece al BrainOS. --- ## §8 · Cadencias y Rituales de Mantenimiento El BrainOS requiere mantenimiento programado, no ad-hoc. La calidad del sistema correlaciona directamente con la disciplina de las cadencias. Las cadencias canónicas son: ### Cadencia diaria · captura continua - Aplicación de Vías 1, 2 y 4 (cuando aparezcan). - Validación de propuestas pendientes en bloque corto (5-10 minutos) al cierre del día. - Verificación de que ninguna señal esplécnica del día se perdió. ### Cadencia semanal · revisión ligera - Aplicación de Vía 5: aporte de outcomes pendientes en bloque de 10-15 minutos. - Revisión del mapa visual si se actualizó. - Verificación de que las propuestas pendientes de validación no se acumulan más de 7 días. - Si hay backlog > 7 días, se trata como deuda del dueño. ### Cadencia mensual · Monthly Distillation - Revisión de las capturas del mes en los archivos de Patrones. - Detección de patrones repetidos (2+ veces) candidatos a lección. - Actualización del mapa visual del BrainOS. - Identificación de thoughts en estado vivo > 6 meses sin outcome. - Sesión dedicada del dueño con el runner: 60-90 minutos. ### Cadencia trimestral · destilación de lecciones - Revisión completa de archivos de Patrones del trimestre. - Identificación formal de patrones confirmados con outcome positivo 2+ veces. - Propuesta de ascenso a Lecciones Activas. - Validación del dueño en sesión dedicada (90 minutos a medio día). - Depreciación formal de thoughts > 12 meses sin outcome. ### Cadencia semestral · revisión de reglas inmutables - Revisión completa de Lecciones Activas. - Identificación de lecciones sostenidas 2+ trimestres consecutivos. - Propuesta de ascenso a Reglas Inmutables. - **Revisión obligatoria con asesor humano externo** (no se sube regla inmutable sin segunda opinión calificada). - Sesión dedicada del dueño: medio día. ### Cadencia anual · revisión del paper del sistema - Lectura completa del paper personalizado del BrainOS del dueño. - Identificación de drift entre lo escrito y la práctica observable. - Actualización del paper (v02, v03, ...). - Reporte al registro maestro del ecosistema si existe (Victor Heredia u otra figura equivalente). Cada cadencia genera un artefacto auditable: minuta de sesión · documento de propuestas · mapa visual · ajuste de paper. **Sin artefacto, la cadencia no se cumplió.** Esta regla es estricta. --- ## §9 · Métricas de Salud del Sistema Cómo saber si el BrainOS está sano. Cinco métricas se reportan en cada mapa mensual: ### Métrica 1 · Tasa de captura Cuántos thoughts nuevos ingresan por mes. - **Saludable:** 5-15 por mes en operación normal del dueño. - **Alerta baja (<3 por mes):** el dueño no está alimentando · revisar disciplina de captura. - **Alerta alta (>25 por mes):** el dueño está usando el BrainOS como journal · revisar filtros y anti-patrones. ### Métrica 2 · Tasa de validación Qué porcentaje de propuestas son validadas vs descartadas por el dueño. - **Saludable:** 60-85%. - **Alerta crítica (100%):** el dueño no está leyendo · valida automáticamente. Riesgo alto de drift. - **Alerta baja (<40%):** el runner no está calibrado al modo de pensar del dueño · está proponiendo mal. Requiere recalibración. ### Métrica 3 · Tasa de outcomes registrados De los thoughts en estado vivo, cuántos tienen outcome registrado dentro de 6 meses. - **Saludable:** >50%. - **Alerta crítica (<25%):** el sistema está acumulando capturas sin confirmar. La fidelidad está en riesgo. Requiere bloque dedicado de outcomes. ### Métrica 4 · Tasa de ascenso Cuántas lecciones ascienden a reglas por semestre. - **Saludable:** 1-3 por semestre. - **Alerta de estancamiento (0 por 2+ semestres consecutivos):** el sistema no destila. Revisar cadencia semestral. - **Alerta de inflación (5+ por semestre):** el dueño está ascendiendo demasiado fácil. Revisar criterio con asesor humano. ### Métrica 5 · Tasa de contradicciones reportadas Cuántas veces por trimestre el dueño marca una contradicción. - **Saludable:** 1-3 por trimestre. - **Alerta de pasividad (0 por trimestre):** el dueño no está leyendo críticamente. - **Alerta de drift real (5+ por trimestre):** hay desalineación significativa entre runner y dueño. Requiere recalibración y posible reescritura del paper. Si dos o más métricas están fuera de rango simultáneamente, se convoca sesión de recalibración con el registro maestro del ecosistema. --- ## §10 · Riesgos Estructurales y Mecanismos de Protección El BrainOS tiene cinco riesgos estructurales conocidos. Cada uno tiene un mecanismo de protección específico: ### Riesgo 1 · Drift del runner El runner SherpaX puede empezar a representar al runner mismo en lugar del dueño. Captura cosas que cree que el dueño piensa pero no son del dueño real. Tendencia a sobre-formalizar o sobre-categorizar según patrones de entrenamiento general. **Mecanismo de protección:** Validación obligatoria del dueño · Métrica 2 (tasa de validación) · Métrica 5 (contradicciones reportadas) · revisión anual del paper · disciplina del dueño de leer críticamente cada propuesta. Si el dueño valida automáticamente sin leer, la protección colapsa. ### Riesgo 2 · Acumulación pasiva El sistema crece pero los thoughts no maduran. Captura sin outcome. Después de 2-3 años, el BrainOS tiene cientos de entradas pero ninguna ha producido lección destilada. **Mecanismo de protección:** Métrica 3 (outcomes registrados) · depreciación automática a 12 meses sin outcome · cadencia trimestral obligatoria · Vía 5 con bloques semanales de 10-15 minutos. ### Riesgo 3 · Captura en estado de sombra cognitiva El dueño valida o propone capturas estando agotado, irritado o emocionalmente cargado. Genera reglas frágiles que después se contradicen. **Mecanismo de protección:** Filtro pre-validación que el runner aplica · si detecta indicadores de sombra (irritabilidad subiendo + output cuesta + frases tipo "no tengo ganas"), posponer validación · regla operativa del propio dueño al respecto, codificada en sus Reglas Inmutables. ### Riesgo 4 · Captura sesgada por urgencia El dueño quiere cerrar todo en un día y valida en bloque sin leer. El sistema termina representando un estado emocional puntual, no criterio sostenido. **Mecanismo de protección:** Validación nunca en sesión donde el canal de entusiasmo prematuro esté activo · cadencia que distribuye validaciones en bloques cortos repartidos en lugar de maratones · regla de no validar bajo presión externa. ### Riesgo 5 · Sesgo del runner por entrenamiento previo El runner puede sesgar propuestas según patrones generales aprendidos en entrenamiento, no según el dueño específico. Tendencia a interpretar señales del dueño según marcos cognitivos genéricos. **Mecanismo de protección:** Revisión anual del paper · contradicciones reportadas (Métrica 5) · revisión semestral de reglas con asesor humano externo · diversificación de runners en el largo plazo si la tecnología lo permite. Ningún mecanismo es infalible aislado. La combinación de mecanismos es lo que sostiene la fidelidad. La protección del BrainOS es un sistema de capas redundantes, no un control único. --- ## §11 · Personalización · Cómo Adaptar el Framework a un Operador Específico Este framework es universal en su arquitectura pero requiere personalización para cada dueño. Las decisiones de personalización se documentan en un paper específico del dueño (ver PAPER-{owner}-BrainOS-Funcionamiento-vXX.md como ejemplo del owner Emilio Heredia). ### Decisiones de personalización requeridas **Decisión 1 · Marco cognitivo del dueño.** Documentar en el Archivo 1 (Perfil del Operador) qué marco usa el dueño para entender su propio sistema de toma de decisiones. Puede ser Human Design, Eneagrama, MBTI, Gene Keys, terapia psicodinámica con marco propio, o cualquier otro marco coherente. Si el dueño no tiene marco previo, el primer trabajo del runner es ayudar a construir uno mínimo viable mediante observación de 2-3 meses de operación. **Decisión 2 · Nombre de los archivos de Patrones.** Los Archivos 4 y 5 (Patrones del Instinto Consciente y Patrones de Entusiasmos a Filtrar) cambian de nombre según el marco del dueño. Ejemplo con Human Design: "Patrones-Canal-32-54" y "Patrones-Canal-29". Ejemplo con marco genérico: "Intuiciones-Validadas" y "Impulsos-Filtrados". Lo importante es que el nombre sea reconocible para el dueño y conecte con su lenguaje interno. **Decisión 3 · Duración de las olas.** El Principio 5 menciona que los entusiasmos prematuros requieren ola antes de capturarse como decisión. La duración exacta de la ola varía por perfil: algunos operadores requieren 24 horas, otros 48-72, otros una semana. Documentar la duración estándar del dueño en su Perfil del Operador. **Decisión 4 · Definición de "sombra cognitiva".** El Riesgo 3 menciona estados de sombra. Cada dueño tiene señales propias de su sombra (agotamiento físico, irritabilidad creciente, dificultad de concentración, falta de palabras). Documentar las señales específicas para que el runner pueda detectarlas. **Decisión 5 · Asesores que el sistema exige.** El Archivo 6 (Asesores Humanos) lista qué frentes requieren asesor humano certificado. La lista varía: algunos operadores necesitan asesor financiero, fiscal, legal y médico como mínimo. Otros agregan terapeuta, coach, mentor estratégico, custodio fiduciario. Documentar la lista mínima en las Reglas Inmutables del dueño. **Decisión 6 · Cadencias adaptadas.** Las cadencias del §8 son recomendaciones. El dueño puede ajustar (ejemplo: Weekly Review puede ser jueves en lugar de viernes, o sábado en lugar de día laboral). Las cadencias se documentan en el paper personal del dueño. **Decisión 7 · Tono y formalidad del runner.** Algunos dueños prefieren runners más formales, otros más coloquiales. Documentar en el Perfil del Operador el estilo deseado. **Decisión 8 · Frases canónicas de activación.** La tabla del Anexo C (Frases Canónicas) puede personalizarse. Si el dueño tiene un lenguaje propio para ciertos disparos, documentarlo y usarlo. ### Lo que NO se personaliza Los cinco principios fundacionales (§2) son no negociables. La arquitectura de tres capas con siete archivos (§3) es estructural. El ciclo de vida de cinco estados (§4) es invariante. La división de trabajo dueño-runner (§5) es estructural. Las cinco métricas de salud (§9) y los cinco riesgos (§10) son universales. Personalizar lo personalizable y respetar lo invariante es la clave para que el framework siga siendo coherente entre operadores distintos. --- ## §12 · Roadmap Evolutivo del Framework Este framework está en versión v01. Se anticipan las siguientes evoluciones: ### Corto plazo · próximos 6-12 meses - Aplicación del framework a 2-3 operadores distintos del ecosistema · comparación de patrones. - Refinamiento de la lista de anti-patrones (§7) con casos observados en operación real. - Refinamiento de las métricas de salud (§9) con datos empíricos de los primeros operadores. ### Mediano plazo · 1-2 años - Acumulación suficiente de datos cross-operador para identificar patrones universales (ej: ¿qué tipo de destellos esplécnicos se confirman más?). - Posible introducción de un octavo archivo si emerge una capa cognitiva no contemplada en v01. - Versionado v02 del framework con ajustes basados en evidencia. ### Largo plazo · 3-5 años - Posible estandarización de protocolos de transferencia parcial del BrainOS de un operador a sucesores (curación de extractos transmisibles). - Posible integración con sistemas asistidos de toma de decisión (BrainOS como input estructurado a otros sistemas). - Posible certificación de runners según estándares del framework. ### Horizonte largo · 5+ años - BrainOS como activo intelectual transferible con metodología certificada. - Adopción por organizaciones que operan con criterio acumulado (firmas familiares, family offices, despachos profesionales). --- ## §13 · Conclusión El BrainOS es un sistema vivo de memoria estructurada con criterio. Su valor reside no en lo que guarda sino en cómo lo guarda: con estados de madurez, con cadencias de destilación, con validación obligatoria del dueño y con mecanismos explícitos contra drift. Es un cerebro externo que mejora con el uso y resiste deriva mientras se respeten sus principios fundacionales. La fidelidad del sistema al modo de pensar real del dueño depende de dos disciplinas mantenidas en el tiempo: la captura no diferida de señales cuando aparecen y la validación activa de cada propuesta antes de su ingreso. Sin captura, el sistema queda vacío y se vuelve cosmético. Sin validación, el sistema deriva y termina representando al runner en lugar del dueño. Ambas disciplinas son responsabilidad indelegable del dueño. Este documento es la referencia canónica del framework BrainOS. Se revisa anualmente y se actualiza si la práctica observable del ecosistema se ha movido. Cualquier discrepancia entre lo escrito aquí y la práctica de un operador específico se documenta en el paper personal de ese operador, no aquí. Este paper canónico cambia sólo cuando hay evidencia cross-operador de que una mejora estructural mejora el sistema para todos. El BrainOS no reemplaza al operador humano. Lo extiende. Esa distinción es el centro del sistema. --- ## Anexo A · Formatos Canónicos por Archivo ### A.1 · Formato Archivo de Patrones del Instinto Consciente ``` ## [FECHA] · [CONTEXTO BREVE] - **Destello:** (texto exacto · literal · sin interpretación del runner) - **Contexto:** (qué ocurría · de dónde vino la señal) - **Outcome validado:** (a completar semanas/meses después · ¿se confirmó?) ``` ### A.2 · Formato Archivo de Patrones de Entusiasmos a Filtrar ``` ## [FECHA] · [PROYECTO / PROPUESTA] - **Entusiasmo detectado:** (descripción · intensidad · señal corporal si aplica) - **Contexto:** (de dónde vino la propuesta) - **Ola aplicada:** (duración · ¿se respetó?) - **Decisión post-ola:** (qué decidió el dueño después de la ola) - **Outcome validado:** (a completar semanas/meses después) ``` ### A.3 · Formato Archivo de Lecciones Activas ``` ## [FECHA DESTILACIÓN] · [CÓDIGO-LECCIÓN] - **Lección:** (enunciado claro · una oración · forma declarativa) - **Contexto:** (de qué experiencia y patrones viene) - **Aplicación:** (cómo se aplica en la operación · forma operativa) - **Status:** [activa / ascendida a regla #XX / deprecada] ``` ### A.4 · Formato Archivo de Asesores Humanos ``` ## [NOMBRE] · [ROL] - **Rol:** (qué función cumple en la red de criterio) - **Estado:** [activo / en proceso / pendiente identificar] - **Especialidad:** (área de criterio) - **Frente cubierto:** (qué eje/frente operativo del dueño) - **Próximo paso:** (acción pendiente con esta persona) - **Notas:** (contexto adicional relevante) ``` ### A.5 · Formato Archivo de Reglas Inmutables ``` ## Regla [NÚMERO] · [TÍTULO CORTO] - **Enunciado:** (regla en una oración · imperativa) - **Origen:** (qué lección ascendió · fecha de ascenso) - **Aplicación:** (cuándo se invoca · cómo se detecta su activación) - **Excepciones:** (ninguna · o explícitas si existen) ``` ### A.6 · Formato Archivo Perfil del Operador Libre, según el marco cognitivo del dueño. Recomendado: secciones por capa (sistema de decisión · canales/atributos activos · sombras conocidas · capítulo de vida actual · estilo natural). ### A.7 · Formato Archivo Tesis Estratégica Libre, según el operador. Recomendado: hipótesis macro de creación de valor · principios estratégicos · alianzas centrales · capítulo de vida. --- ## Anexo B · Checklist Semanal del Dueño Bloque sugerido de 10-15 minutos, frecuencia semanal: ``` □ ¿Hay propuestas pendientes de validar de esta semana? Validarlas. □ ¿Hay outcomes pendientes de aportar a thoughts vivos? Aportar 1-3. □ ¿Apareció alguna señal esplécnica esta semana? ¿Se capturó? □ ¿Filtré algún entusiasmo prematuro? ¿Lo reporté? □ ¿Hay alguna contradicción que detecté entre lo escrito y lo que pienso hoy? □ ¿El mapa visual del BrainOS está actualizado a esta semana? ``` Si hay tres respuestas "no" consecutivas, abrir sesión de recalibración con el runner. --- ## Anexo C · Frases Canónicas de Activación Frases del dueño que disparan acciones específicas del runner. Las frases son canónicas pero pueden personalizarse en el paper específico del dueño: | Frase del dueño | Acción del runner | |---|---| | *"Captura esplécnica: [destello literal]"* | Formatea y nomina en Archivo de Patrones del Instinto Consciente | | *"Filtré un entusiasmo sobre [X]"* | Abre formato del Archivo de Patrones de Entusiasmos y pregunta los campos | | *"Sumar a [nombre] como asesor en [frente]"* | Formatea entrada en Archivo de Asesores Humanos | | *"¿Cómo terminó [X capturado en Y fecha]?"* | Pregunta al dueño · registra outcome | | *"Hay una contradicción en [archivo]"* | Abre discusión · propone resolución | | *"Estado del BrainOS"* | Reporta las cinco métricas + mapa visual actualizado | | *"Destilar este trimestre"* | Inicia destilación trimestral formal | | *"Revisar reglas"* | Inicia revisión semestral con asesor humano convocado | | *"Revisar paper"* | Inicia revisión anual del paper personal del dueño | --- ## Anexo D · Vocabulario Controlado Términos técnicos del framework. Su uso es preciso · no intercambiable: - **BrainOS:** el sistema canónico completo (los siete archivos + protocolos + cadencias + dueño + runner). - **Thought:** unidad mínima de captura en el sistema. - **Destello esplécnico:** señal del instinto consciente del dueño · captura no diferible. - **Entusiasmo prematuro:** impulso de compromiso antes de procesar la ola interna · captura diferida. - **Ola:** lapso temporal entre detección de entusiasmo y decisión post-procesamiento interno. - **Patrón:** thought que se ha observado 1-2 veces · candidato a lección. - **Lección:** patrón confirmado 2+ veces · candidato a regla. - **Regla inmutable:** lección confirmada en el tiempo · ascendida formalmente con asesor humano. - **Validación:** acto del dueño de autorizar ingreso de un thought al sistema. - **Outcome:** confirmación o refutación con datos reales del thought original. - **Ascenso:** movimiento de un thought a un estado de mayor madurez. - **Depreciación:** marcado de un thought como no-validado tras período sin outcome. - **Drift:** desalineación entre el modelo del runner y el modo de pensar real del dueño. - **Sombra cognitiva:** estado del dueño en que su capacidad de validar está comprometida (agotamiento, irritabilidad, presión). - **Cadencia:** ritmo programado de mantenimiento del sistema. - **Runner SherpaX:** instancia de inteligencia artificial asistente que opera el BrainOS junto al dueño. - **Dueño:** operador humano titular del BrainOS · único autorizado a validar. - **Registro maestro del ecosistema:** figura de auditoría externa del sistema · supervisa coherencia entre operadores. --- ## Anexo E · Bitácora de Versiones del Paper Canónico | Versión | Fecha | Cambio | Disparador | |---|---|---|---| | v01 | 2026-05-13 | Documento canónico inicial · arquitectura, ciclo, cadencias, riesgos, personalización, roadmap. Renombrado de PAPER-FW- a CP- y reubicado a IB-XX-Maestro/IPI-XX-Corp-Brain-OS/ por revisión canónica de Jay (custodio). Contenido íntegro preservado de la versión generada por EmilioX. | Solicitud de framework canónico no específico a un dueño · derivado del paper personal de Emilio Heredia · ratificación pendiente Victor | --- *Paper Canónico · El BrainOS · Framework de Memoria Viva con Criterio · v01 · 2026-05-13* *Producido por: EmilioX (mantenedor inicial · sesión con Emilio Heredia)* *Custodio canónico: Jay (IB-XX-Maestro)* *Ubicación canónica: IB-XX-Maestro / IPI-XX-IP-Infraestructura / IPI-XX-Corp-Brain-OS / CP-XX-BrainOS-MetodologiaFramework-v01.md* *Próxima revisión programada: mayo 2027 · o antes si hay evidencia cross-operador de mejora estructural.*