🏛 Gobierno del Repo y del Storage¶

Sistema de Decisión Asistida (SDA) — BKM¶

1. Propósito de este documento¶

Este documento define cómo se organiza, gobierna y separa la información del Sistema de Decisión Asistida (SDA) de BKM entre:

el Repositorio (Repo), y
el Storage.

Su objetivo es:

eliminar ambigüedades sobre dónde vive cada tipo de información,
garantizar trazabilidad y control,
proteger el gobierno del sistema,
y permitir que la IA asista decisiones sin comprometer el diseño ni la coherencia.

Este documento forma parte del gobierno del sistema y es de cumplimiento obligatorio para personas, procesos y agentes de IA.

2. Principio rector¶

El Repo define cómo funciona el sistema.
El Storage registra lo que ocurre cuando el sistema se utiliza.

Ambos son necesarios, pero no cumplen el mismo rol
y no deben mezclarse bajo ningún concepto.

3. Definición del Repo¶

El Repo es el repositorio Git del SDA de BKM, gestionado desde VS Code y versionado mediante control de cambios.

Rol del Repo¶

El Repo es la fuente de verdad normativa del sistema.

Contiene documentos que:

definen reglas y principios,
establecen límites explícitos,
describen procesos y marcos de decisión,
fijan plantillas oficiales,
y gobiernan el uso de la IA dentro del SDA.

Características del Repo¶

Versionado explícito (Git).
Cambios conscientes y revisables.
Edición humana.
Evolución controlada.
No contiene resultados operativos recurrentes.

4. Qué vive en el Repo¶

En el Repo deben vivir siempre los documentos que definen el sistema.

4.1 Gobierno y marco¶

README del proyecto.
Visión y principios del SDA.
Marco de Decisiones asistidas por IA.
Manual de Gobierno del Sistema.
Roles y responsabilidades.
Gobierno Repo ↔ Storage (este documento).
Gobierno de datos estructurados.
Reglas de acceso y lectura (a nivel conceptual).

4.2 Diseño del sistema¶

Catálogo de decisiones.
Fichas de decisión (como definición base, no ejecución).
Definición de agentes (misión, límites, responsabilidades).
Prompts versionados y aprobados.
Playbooks operativos.
Templates oficiales.

Regla clave¶

Todo lo que define cómo se trabaja y se decide vive en el Repo.

5. Qué NO debe vivir en el Repo¶

El Repo no es un repositorio operativo ni un archivo histórico.

No deben vivir en el Repo:

outputs semanales o recurrentes,
resultados generados por IA en ejecución,
logs de decisiones tomadas,
snapshots históricos,
documentos que crecen indefinidamente,
evidencias operativas,
archivos grandes o binarios.

Todo lo anterior pertenece al Storage.

6. Definición del Storage¶

El Storage es el sistema de almacenamiento documental operativo del Sistema de Decisión Asistida de BKM.

Rol del Storage¶

El Storage actúa como:

Sistema de Registro Operativo (System of Record)
del uso real del SDA.

Refleja qué ocurrió realmente cuando el sistema fue utilizado:

qué información se usó,
qué outputs se generaron,
qué evidencias se consideraron,
y qué decisiones humanas se tomaron.

7. Qué vive en el Storage¶

En el Storage viven los resultados del uso del sistema, no su definición.

7.1 A nivel de decisión¶

Outputs generados por la IA.
Resultados periódicos (ej. semanales).
Snapshots de información usada para decidir.
Registros de decisiones humanas.
Evidencias documentales o visuales.
Históricos fechados.

7.2 A nivel global¶

Resúmenes ejecutivos consolidados.
Comparativas históricas.
Outputs agregados de múltiples decisiones.

Regla clave¶

Todo lo que es resultado del uso del sistema vive en Storage.

8. Versionado y naming en Storage¶

El Storage no utiliza control de versiones Git.

El versionado se gestiona mediante:

estructura de carpetas,
convención de nombres,
fechas explícitas.

Ejemplo¶

outputs/ ├── 2026-01-08_output.md ├── 2026-01-15_output.md └── latest.md

Reglas obligatorias¶

Los históricos no se sobrescriben.
latest.md apunta al último output válido.
Cada documento debe ser trazable en el tiempo.

9. Relación entre Repo y Storage¶

Repo	Storage
Diseño y gobierno	Ejecución y evidencia
Reglas y principios	Resultados reales
Plantillas	Instancias concretas
Definiciones	Outputs
Control de cambios	Histórico operativo

Regla de precedencia¶

En caso de conflicto:

El Repo siempre prevalece como fuente de verdad normativa.

10. Escritura y acceso (visión general)¶

Personas¶

Editan el Repo.
Aprueban cambios de diseño.
Revisan y validan outputs en Storage.

IA / Agentes¶

❌ No escriben en el Repo.
✔️ Leen información permitida desde Storage.
✔️ Escriben outputs exclusivamente en Storage.

Esta separación no es técnica, es de gobierno y obligatoria.

11. Errores comunes que se deben evitar¶

Usar el Repo como si fuera un Drive.
Subir outputs operativos al Repo.
Editar documentos de diseño desde Storage.
Duplicar documentos entre Repo y Storage.
No distinguir entre plantilla y documento instanciado.

12. Idea clave final¶

Un Sistema de Decisión Asistida bien gobernado
no depende de la tecnología,
sino de dónde vive el conocimiento y quién puede modificarlo.

Este documento existe para garantizar esa claridad en el SDA de BKM.

✅ Estado del documento¶

Con este documento:

queda cerrada la frontera Repo ↔ Storage,
el sistema es auditable y escalable,
y se elimina una de las principales fuentes de degradación en proyectos de IA y datos.